Linux 6.12

Po 9 týdnech vývoje od vydání Linuxu 6.11 oznámil Linus Torvalds vydání Linuxu 6.12. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies. Po dvaceti letech byla do upstreamu začleněna real-timová podpora (PREEMPT_RT).

18.11.2024 03:44 | Ladislav Hagara | Nová verze

Komentáře

[Max]

Další peklo zamrzlo.
Zdar Max

[jx zero]

Proc? Kvuli tomu realtimu?

[Max]

Ano. Patche ohledně RT jsou tu s námi od počátku věků a až nyní to vypadá, že bude vše čistě pořešeno a začleněno.
Zdar Max

[PetebLazar]

Vydavatelé distribuce Ubuntu Studio ve verzi 24.10 přešli z LowLatency Kernelu na Generic Kernel s low-latenci options. https://ubuntustudio.org/2024/10/ubuntu-studio-24-10-released/

Jako důvod nenasazení Real-Time Kernelu pro UbSt je v minulosti zmiňována bezpečnost. https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel

[Pavel Píša]

To, co píší není pravda. Zlovolný task s RT prioritou i na jádru s velkými latencemi a nepreempibilními spinlock sekcemi vybere stejné procento procesorového času jako na PREEMPT_RT jádře, protože má absolutní přednost. Ale ochrana tam a i pro PREEMPT_RT konfiguraci je, a to je maximální bandwidth, který si v nějakém čase mohou SCHED_FIFO a SCHED_RR procesy nebo spíše správněji vlákna alokovat. Limit je možné nastavit v /proc/sys/kernel/sched_rt_period_us a /proc/sys/kernel/sched_rt_runtime_us, kde standardní hodnoty definují že z 1000000 usec (1 sec) si RT tasky mohou vzít maximálně 950000 usec, tedy 95% výkonu může být zabraných RT tasky a zbytek je SCHED_OTHER a další, tedy i k RT tasky přetíženému systému se lze připojit třeba přes SSH a dát věci do pořádku. Pokud se procenta nastaví na méně, nebo se poladí i granularita, tak i při splašeném RT tasku není problém situaci napravit a při určitém nastavení to asi ani nebude moc vidět. Problém nastane pokud splašený RT task bude mít prioritu nad prioritami tasků, které v RT obsluhují přerušení (ta je standardně 50). Pak začnou být zařízení (myš, klávesnice, síť, disky, video...) blokovaná. Ale není problém přes ulimit třeba v PAM nastavit uživatelům maximální povolenu RT prioritu na 49 nebo třeba s rezervou 40.

Obecně je tedy tvrzení chybné a šíří dezinformace.

[PetebLazar]

Dezinformace je definována jako nepravdivá informace, která je záměrně šířena za účelem oklamání lidí.

Co Vás vede k tvrzení, že v případě autora dané stránky na Wiki Ubuntu Studio Ericha Eickmeyera (audio inženýr) nešlo o pouhý omyl (či projev neznalosti dotyčné problematiky)? Nařčení ze šíření dezinformací připisuje dané osobě nekalý záměr. Jsou pro to nějaké konkrétní důkazy, nebo šlo jen o nevhodnou formulaci?

[Pavel Píša]

OK, možná jsem se nechal příliš unést, ale právě pokud takovouto informaci tvrdí někdo, kdo se prohlašuje za odborníka a mnou uvedené informace si mohl snadno dohledat, tak mě to dost popuzuje. Je možné, že se mu podařilo v nějaké chvíli dojít k zablokování počítače atd. a k RT verzi získal záporný vztah. Ale i v tom případě měl hledat a uvést alespoň, jak je možné se proti tomu bránit. Takže pokud by informaci tvrdil běžný student, uživatel, tak mě to nenadzvedne. Ale zde to považuji za šíření škodlivé informace a minimálně z důvodu vlastního selhání ve své deklarované odbornosti.

Jinak Debian má v nabídce RT jádro asi již i po desetiletí bez velkých vln. Obecně nějak nemám k Ubuntu sám ideální vztah. Tím, že je často prohlašované za ideální startovací distribuci, tak ho nakonec i na vyzkoušení doporučuji, ale jinak se mi přístup ze začátku vysloveně okázalé nespolupráce s jejich upstreamem - Debianem a prohlašování že jsou lepší za každou cenu, moc nelíbil. Ale z mého ne příliš soustředěného pozorování se mi zdá se, že se to časem nějak zlepšilo.... V Debian "Developer Information" jsou tackované Ubuntu verze, tak snad alespoň i tam Ubuntu vývojáři přispívají, i když zpětný odkaz z Ubuntu balíčků na Debian najít nemohu... Takže nevím... Obecně jsem u prohlášení ze strany Ubuntu hodně opatrný a dost se mi to osvědčuje, a to i zde...

[PetebLazar]

Text kde se autor za odborníka v dané problematice prohlásil jsem asi přehlédl. Docela by mne zajímalo jak se taková věc vlastně formuluje.

Já to pochopil tak, že Ubuntu Studio je příchutí Ubuntu, ale není přímo distribucí z dílny Ubuntu Foundation/Canonical Ltd., její vznik snad leží na bedrech komunity "Ubuntu Studio Project" se značným zastoupením lidí z hudební branže. U nichž se patrně propojuje vztah k hudbě a hudební produkci s láskou k Linuxu. V opačném případě by tito asi řešili "upgrade" Maců a "privátnost" Windows.

Při širším záběru se lidé logicky často spokojí s omezenou hloubkou poznání(good enough v případě vlatního řešení), což je nezbytností při snaze obsáhnout komplexní často interdisciplinárni problematiku. Odborníci co se specializují na úzký obor pak naproti tomu mohou minout širší souvilosti. Ani jedna z těchto skupin si nezaslouží ostrakizaci za svůj přístup pokud je veden dobrou vůlí a přináší výsledky co neškodí. Samozřejmě na případné chyby je třeba upozornit, nakonec i z těch se učíme.

[Peter Golis]

Za odborníka sa môže pasovať každý, rovnako ako sa môže pasovať hoci aj za lietadielko. Tak isto môže ktokoľvek prehlásiť akýkoľvek zdroj za dôveryhodný. Máme predsa slobodu prejavu. Bez toho by sme nemali napríklad ani Vianoce.

[VoDo]

uz je to sechno v rustu a bez ruska?

[..... Izak .....]

RT je jen k rizeni stroji, popr low latency edirtace muziky, ale kdo ma dnes skutecne MIDI pres optiku ? , jinak k nicemu.

Problem RT je nizky vykon, musi bezet mikro kernel, co ridi kernel, aby zajistil aplikaci pristup k HW na castove bazi, spatne nastaveni vede k DOS, nebo prestizni HE jednim procesem a nic jineho se ke slovu nedostane ... ano bezpecnsot ani stabilita obecneho systemu to neprida.

Zato je RT super, pokud to bezi v single mode, nebo tam nic jineho nebezi, s nejakym rozumnym nastavenim a je tam max nejakay management - pak je RT super a velice potrebne, ale nasadit RT na bezne uzivani, nebo nedej boze na vytizeny server je uplna blbost ... dnes se casto resi linux v single mode, vtyladeny, nebo dokonce FreeDOS - nebot moderni HW ma bezne latence i bez RT na urovni, ze to bohjate staci ... kde to nestaci, nastupuje RT a je to tak v poradku, ale nepredsdtavujme si, ze je to dobre na desktop, nebo na server - neni, je to spise zatez a v tomto pripade k nicemu az na skodu

[Pavel Píša]

Ano existují projekty, kdy je RT řešený mimo jádro Linux, Xenomai, RTai, Xtratum, L4 Linux a další. Ale úprava, která se dostala do mainline Linuxu ve verzi 6.12 je úprava plánovače a infrastruktury jádra, které sekce chráněných spin_lock_irqsave mění na sekce chráněné RT mutexy s priority inheritancí. Dále jsou obslužné rutiny přerušení spouštěné v dedikovaných vláknech/kernel tascích. Tedy zde není žádné druhé jádro, nebo hypervisor. Ano, změna na RT mutexy o něco běh zpomaluje. Zároveň zkrácení latencí při přepínání běžných, ne RT, tasků někdy vede ke ztrátě určité, vějšinou ale malé, části výkonu proti běžné konfiguraci jádra. Ale zde plná verze RT patchů nabízí odložení přepnutí (PREEMPT_LAZY), takže pro ne RT tasky se docílí snížení overheadu. Naopak různé pokustničení s low latency nepeemptivním jádrem je spíše na škodu a roznáší po kódu jádra mnoho zbytečných maker pro vložení testu na preempci a do budoucna asi odložené přepínání s PREEMPT právě i díky práci PREEMPT_RT komunity nabídne lepší využitelnost jádra na desktopu. PREEMPT_RT pak často díky přesunu řešení přerušení do plnohodnotných tasků pro hodně zatížené systémy může vést k zlepšení chování i tehdy, když vlastní (hard) RT není potřeba. Takže nemyslím si, že je to tak jednoznačné a cvičně jsem desktop s RT patchi provozoval již i na začátku s jádry 2.6.18 a bylo to v pohodě. Dlouhodobě si pak myslím, že postupně jádro přejde i na serverovových úlohách na přesun interuptů do RT theradů a možná se i tam nakonec přejde na LAZY a pak možná i na plný PREEMP a PREEMP_RT. Nakonec celkem velkou část vývoje RT před delší dobou platila IBM aby obstála požadavkům burz cenných papírů na zaručení obchodování na burzách v reálném čase (s garancí milisekunt). Za sebe si myslím, že to bylo spíše přechané, ale na druhou stranu jádro v konfiguracích mimo PREEMP_RT nenabízí garance téměř žádné a ve specifických situacích se mohou objevit latence téměř libovolné, sekunda atd... RT jádro sice analytickou garanci nedává také, ale dobře nakonfigurované stroje vykazují dodržení latencíc v desítkách nebo pro ARM ve stovkách mikrosekunt při všeožné zátěži po roky testů, viz třeba OSADL QA Real-Time Farm https://www.osadl.org/OSADL-QA-Farm-Real-time.linux-real-time.0.html.