Jaderné noviny – 18. 11. 2010: Skupinové plánování a odezva desktopu

8. 12. 2010 | Jirka Bourek | Jaderné noviny | 3549×

Aktuální verze jádra: 2.6.37-rc2. Citáty týdne: Rusty Russel, Linus Torvalds, Ingo Molnár. Vyrážení děr do souborů. Skupinové plánování založené na TTY.

Obsah

• Aktuální verze jádra: 2.6.37-rc2
• Citáty týdne: Rusty Russel, Linus Torvalds, Ingo Molnár
• Vyrážení děr do souborů
• Skupinové plánování založené na TTY

Aktuální verze jádra: 2.6.37-rc2

Současné vývojové jádro je 2.6.37-rc2 vydané 15. listopadu. A všechno vypadá tak, jak rád vidím, když -rc2 vypadá: není tam nic zajímavého. Většinou obsahuje opravy, ale také nějaké zbytky práce na odstranění velkého jaderného zámku, konečné odstranění podpory tvrdých bariér z blokové vrstvy a pár nových LED ovladačů. Detaily vizte v kompletním changelogu.

Po vydání -rc2 byla začleněna významná změna API ovladačů: funkce ze střední vrstvy [midlayer] SCSI queuecommand() se nyní volá bez zámku hostitele; prototyp funkce se změnil také.

Stabilní aktualizace: žádné nevyšly od 29. října.

Citáty týdne: Rusty Russel, Linus Torvalds, Ingo Molnár

Všichni chceme budovat infrastrukturu; když jsou ji ostatní vývojáři nuceni používat, stoupáme v hierarchii jaderné dominance. Ook ook! (Ze stejného důvodů má každá unixová aplikace svůj vlastní jazyk pro konfiguraci: autor destiluje mentální námahu uživatelů do jakéhosi Elixíru programátorské arogance.)

Přitom abstrakce věci zesložiťují: snažme se tedy odolat našim pradávným instinktům přidávat retardéry na již tak dlouhou cestu k poznání jádra.

-- Rusty Russel

A nakonec, celé to „uživatelský prostor je flexibilnější“ je jenom lež. Prostě to nakonec není pravda. Bude těžší nakonfigurovat nějakého démona v uživatelském prostoru než prostě nastavit nějaký příznak v /sys nebo něco takového. „Flexibilita“ bývá spíš flexibilitou udělat něco špatně než skutečná výhoda.

-- Linus Torvalds

Naším skutečným problémem, co se sledování týče, je nedostatek relevance, funkčnosti a průrazné analytické síly.

-- Ingo Molnár

Vyrážení děr do souborů

napsal Jonathan Corbet, 17 listopadu 2010

Souborové systémy XFS a OCFS2 v současnosti mají možnost „vyrazit do souboru díru“, tedy označit část souboru jako nepotřebnou, takže se s ní spojený úložný prostor uvolní. Josef Bacik usoudil, že tato vlastnost by mohla být v blízké budoucnosti přidána do ostatních souborových systémů, takže by jádro pro vyrážení děr mělo nabízet standardní rozhraní. Výsledkem je rozšíření systémového volání fallocate(), které tuto možnost přidává.

Konkrétně patch přidává nový příznak (FALLOC_FL_PUNCH_HOLE), který systémové volání rozpozná. Pokud souborový systém je schopen danou operaci provést, daný rozsah dat bude ze souboru odstraněn; jinak se vrátí ENOTSUPP. Současná implementace nezmění velikost souboru; jestliže budou „vyraženy“ bloky na konci souboru, soubor si zachová stejnou velikost. Trochu se diskutovalo nad tím, jestli by měla být změna velikosti souboru podporována, ale zdá se, že v současnosti je konsenzus takový, že by to přineslo víc problémů, než vyřešilo.

Skupinové plánování založené na TTY

napsal Jonathan Corbet, 17 listopadu 2010

Dokud budeme mít desktopové systémy, budou se téměř určitě řešit záležitosti ohledně jejich interaktivity. Během let přišlo a odešlo mnoho komplexních schémat pro zlepšení interaktivity; u většiny z nich byla přinejmenším část uživatelů nespokojená. Zázračné léky se shánějí těžko, ale zdá se, že nedávný patch se k tomu přiblížil... přinejmenším pro některé uživatele. Zajímavé je, že je to konceptuálně tak jednoduché řešení, že možná ani nebude muset být v jádře.

Základní myšlenka zcela férového plánovače [CFS, completely fair scheduler] je jeho naprostá férovost: jestliže o CPU soupeří N procesů se stejnou prioritou, pak každý dostane 1/N dostupného času CPU. Tato politika nahradila poměrně komplikované heuristiky „interaktivity“, které najdeme v plánovači O(1); ve většině situací na desktopu podává lepší výsledky. Tento přístup nicméně v některých situacích selže. Jestliže uživatel spustí deset instancí překladače pomocí make -j 10 společně s aplikací pro přehrávání videa, každý proces dostane „férových“ 9% CPU. Těchto 9% nemusí stačit na to, aby si uživatel užil video tak, jak by chtěl. Není tedy překvapením, že většina uživatelů „férovost“ vidí jinak; nebylo by hezké, kdyby překlad jako celek dostal 50% a přehrávání videa druhou polovinu?

Jádro je schopné zajistit tuto férovost již léta pomocí skupinového plánovače. Sada procesů vložená do jedné skupiny dostane férový podíl na času CPU přiděleného celé skupině, ale skupiny samy budou soupeřit o férový podíl na CPU. Takže pokud bude přehrávač videa vložen do jedné skupiny a překlad do jiné, pak každá dostane polovinu dostupného času CPU. Různé procesy pracující na překladu potom dostanou férový podíl na polovině, která patří jejich skupině; budou soupeřit samy mezi sebou, ale ne s přehrávačem videa. Toto nastavení zajistí, že přehrávač dostane čas CPU, aby stíhal zpracovávat proud dat a plnit všechny požadavky na interaktivitu.

Skupiny jsou tedy hezkou vlastností, ale od doby, kdy byly v 2.6.24 začleněny, se příliš nepoužívaly. Důvody jsou jasné: pro nastavení vyžadují práci administrátora a oprávnění superuživatele; většina uživatelů neví, jak je vyladit a nechtějí se to učit. Co celé ty roky chybělo, je zajistit, aby skupinové plánování pro běžné uživatele „prostě fungovalo“. To je cílem patche pro skupinové plánování podle TTY, jehož autorem je Mike Galbraith.

V krátkosti tento patch automaticky vytvoří skupinu spojenou s každým TTY v systému. Všechny procesy, jejichž řídícím terminálem je dané TTY, budou vloženy do odpovídající skupiny; kód skupinového plánování potom může sdílet čas mezi skupinami procesů podle jejich řídících terminálů. Překlad je obvykle zahájen příkazem „make“ v okně emulátoru terminálu; tato úloha bude mít jiný řídící TTY než přehrávač videa, který nemusí mít žádný řídící TTY. Výsledkem tedy je, že seskupování podle TTY automaticky oddělí úlohy spuštěné v terminálech od úloh spuštěných pomocí správce oken.

Z tohoto chování je Linus šťastný; Linus je koneckonců přesně ten druh člověka, který by mohl do čekání na vysoce paralelní kompilaci jádra propašovat jedno rychlé video. Řekl:

Takže si myslím, že tohle je rozhodně jeden z těch patchů se „skutečným zlepšením“. Dobrá práce. Skupinové plánování se tím mění z „užitečné pro některé specifické serverové zátěže“ na „to je skvělá vlastnost“.

Ostatní také nahlásili významné zlepšení odezvy desktopu, takže tato vlastnost vypadá jako jedna z těch, která má nadprůměrné šance dostat se v příštím začleňovacím okně do hlavní řady. Je tu nicméně několik nesouhlasných hlasů, přičemž většina z nich si myslí, že TTY je špatný ukazatel pro to, do které skupiny proces umístit.

Nejotevřenější – jako to obvykle bývá – je Lennart Poettering, který prohlásil, že spojit něco takového s TTY je prostě praštěné; raději by viděl něco, co je založené na sezeních [sessions]. A, jak řekl, tohle by bylo lepší udělat v uživatelském prostoru. Linuse to, když to řekneme slušně, neohromilo, ale Lennart opětoval palbu několika řádky v bashi, které dosáhnou stejných výsledků jako Mikeův patch – bez nutnosti jakkoliv patchovat jádro. Ukazuje se, že práce s řídícími skupinami není tak těžká.

Linusovi se nicméně stále líbí jaderná verze, hlavně protože může „prostě fungovat“ bez jakéhokoliv zásahu uživatele:

Řečeno jinými slovy: jestliže najdeme lepší způsob, jak něco udělat, neměli bychom říkat „no, jestliže to uživatelé chtějí, mohou udělat <zde doplň technickou věc>“ Jestliže je ten způsob opravdu lepší, prostě bychom to tak měli udělat. Vyžadovat nastavení od uživatele není vlastnost.

Jinými slovy zlepšení, které se prostě objeví s jádrem, bude pravděpodobně k dispozici více uživatelům, než něco, co vyžaduje, aby každý uživatel udělal (jednorázovou) ruční změnu.

Lennart nesouhlasí. Skutečné řešení v uživatelském prostoru, říká, nebude znamenat, že si uživatelé budou muset editovat svoje .bashrc; také bude mít podobu „prostě funguje“. Mělo by to přijít jako malé překvapení v podobě, kterou si představuje v systemd; zdá se, že v budoucnu se plánuje, že systemd převezme správu sezení; v tom okamžiku bude snadné založit skupinové plánování právě na sezení. Lennart věří, že toto řešení bude flexibilnější; bude moci seskupovat procesy způsobem, který dává pro „běžné uživatele desktopů“ větší smysl než seskupování založené na TTY. Také se kvůli tomu nebude muset aktualizovat jádro.

Další nápad, který byl navržen, je přidat pro desktopové spouštěče aplikací možnost „spustit v samostatné skupině“, což by uživateli snadno umožnilo mít kontrolu nad tím, jak se budou aplikace dělit.

Linus podle všeho neustupuje od jaderné verze patche:

A navíc, podle mě je depresivní, že když je to teď vyřešené, lidi vylezou z lesa a řeknou „hej, mohlo by se udělat tohle“. Kde jste byli před rokem?

Těžké. Zjistil jsem, že to můžu vyřešit pomocí řídících skupin, požádal jsem lidi o komentář a pomoc a myslím si, že jaderný přístup je skvělý a mnohem jednodušší, než skripty, které jsem viděl. Ano, jsem zaujatý („jádra jsou snadná – správa uživatelského prostoru přináší velké problémy“)

Příští začleňovací okno lze nicméně očekávat až v lednu; to je docela slušné množství času, aby lidé demonstrovali jiné přístupy. Jestliže se řešení v uživatelském prostoru ukáže jako flexibilnější a v dlouhodobém měřítku efektivnější, stále může vyhrát. To platí obzvláště proto, že začlenění Mikeova patche nijak nepřekáží řešením v uživatelském prostoru; jestliže přístup založený na systemd předvede lepší výsledky, distributoři se jej mohou rozhodnout používat. Tak jako tak se zdá, že lepší interaktivní odezva se objeví v blízké budoucnosti.

       

Komentáře

[Marián Kyral]

Napadá někoho v jakých situacích nastává potřeba mít ze souborů ementál?

[Q]

Co třeba práce s binárními soubory (databáze?). Vymažes data ze souboru od X do Y a tohle místo zcela uvolníš.

[Atom321]

Např. obraz disku v souboru. 100GB virtuální disk zaplněný z 20% pak nezabere z fyzického 100, ale třeba jen 20-25GB.

[pavlix]

Děravé soubory existují už dlouho, viz výše, vtipné je, že jak jednou soubor zaplníš, už nikdy prostor nevrátíš.

[David Watzke]

Fakt? To není vtipný, ale hrozný.

[pavlix]

Mno, je to situace, se kterou žijem už docela dlouho... něco jako nedostatečný systém oprávnění na linuxu (a to myslím včetně těch chudých ACL, co tam jsou).

[Luboš Doležel (Doli)]

Vyvíjí se vůbec POSIX co se API systému týče? Myslím si, že by prvotní iniciativa měla jít odtud. Když vidím věci jako epoll / kqueue / /dev/poll, tak si říkám, že unixu chybí standardizace a pak si každý unix dělá, co chce a kdy chce.

[pavlix]

Vyvíjí se vůbec POSIX co se API systému týče?

Pokud vím, tak minimálně.

Myslím si, že by prvotní iniciativa měla jít odtud. Když vidím věci jako epoll / kqueue / /dev/poll, tak si říkám, že unixu chybí standardizace a pak si každý unix dělá, co chce a kdy chce.

Tak ona standardizace (a hlavně unifikace) unixového API byla vždycky spíše dodatečná. Oblíbená nestandardní rozšíření se postupně dostávala do standardnu. A já si myslím, že to není špatná cesta.

Podle mě je ideálním standardem pro rozhraní operačního systému jen kratičký text, ve kterém se nachází seznam odkazů na dílčí standardy, které je třeba podporovat, aby se člověk mohl hlásit k podpoře standardu. Podporuje to možnost rozdělení práce a nevznikají tisícistránkové dokumenty.

A zrovna přístupová práva jsou v POSIXu stále stejná (draft ACL můžeme s klidem zanedbat jako nestandardní a nedotažený).

Ono je zajímavé, že na poli ACL jsou na tom oproti Linuxu už líp i windows (a tuším i MacOSX a Solaris, ale nezkoumal jsem detailně).

Jediné, co vidím jako šanci na nápravu je NFSv4 ACL zavedené do běžných filesystémů.

[m;)]

nuz, tie windows na tom boli lepsie uz davno, zda sa. nfs v4 acl su nimi inspirovane. a odtial sa dostali napr do zfs a teda do solarisu a dalej do freebsd, kde uz existuje moznost volby ci filesystem bude pouzivat posix alebo nfs4 acls.

[Thunder.m]

Hezky popsané plánovače, dík'

[Jiří J.]

Přidám něco z pozdějších "novinek" na lkml:

Linus je dost tvrdohlavý na to, aby jadernou verzi autogroup scheduleru protlačil do hlavní řady. Ospravedlňuje to tím, že jde v podstatě "jen o heuristiku, kterou jde vypnout". Mike mu taky nahrál čtvrtou verzí patche, která staví na SID (session id) místo TTY.

Podle mě Lennartova pointa taky není špatná - je hodně těžké rozlišit, které aplikace potřebují svoji groupu a které ne. IMHO to z kernelu prakticky nejde poznat. Tím se logicky dostáváme do userspace, který by měl nějak kernelu napovídat. Současný cgroups interface je moc odporný a "generic" na tento typ úlohy, takže tipuji, že ve výsledku dojde jak na patch na straně kernelu, který bude dělat něco málo a navíc přidávat několik sysfs položek, pomocí kterých bude moci userspace snadno ručně "dolazovat" to, co heuristika nezvládla, tak na userspace "patch".

Starý dobrák Con Kolivas se taky vyjádřil a podle mě dobře. Ač byla některá jeho tvrzení vyvrácena / zpochybněna, jeho "latnice" tunable nemusí být až tak špatný nápad. Minimálně naznačuje, že kernel si bez nápověd z userspace moc neporadí, což opět směřuje k tomu sysfs interface.

Závěrem snad jen to, že z group scheduling se stala mediální bublina - v běžném workloadu běžného desktop usera nepomůže prakticky vůbec. Pomůže v Linusově případě make -j64, pomůže v případech programů s tunou forků / vláken, které by mohly prakticky ovlivnit jiné uživatelem přímo používané aplikace, ale takových případů není moc.

Osobně vidím daleko větší problém v I/O scheduleru - v současné době si nemůžu pustit video ve vlc, pokud něco kopíruji z disku na disk, ani nice, ani ionice nepomůže, video se bude pořád zasekávat. To mi přijde jako daleko větší problém, než make -j64. A ne, group scheduling tomu jednomu cp procesu s jedním vláknem nepomůže.

[Karry]

+1

trocha IO aktivity má na odezvu desktopu mnohem horší důsledky... nedejbože když jádro usoudí že by mohlo trochu paměti odswapovat :(

[JoHnY2]

MS mel stejnej problem az do Visty a vyresil to docela silenou metodou, ktera funguje tak, ze aplikace prehravajici media se nabonzuje systemu a ten ji v ramci IO planovani vynuti vyssi prioritu. A stejne to nepomaha pokud jsou na jednom disku dve partitiony, kde na jedny se intenzivne kopiruje a z druhy se chce prehravat video.

[Jiří J.]

On je problém v té propustnosti. Čistě teoreticky by skutečně "kompletně" férový plánovač (CFQ) měl férově rozdělovat přístup k disku rovnoměrně (ne podle počtu přenesených dat, ale podle I/O time), tedy přehrávač by neměl mít problém načíst jednou za 10 sekund 400KB dat, pokud na pozadí kopíruje dd rychlostí 130MB/s.

Někde ale scheduler selhal - tedy on se spíš snaží udržet vysokou propustnost a co nejlépe využít cache, takže místo toho, aby jednou za 10 sekund umožnil okamžitý přístup přehrávači, tak požadavek na čtení zařadí a bude doufat, že v dohledné době někdo jiný přečte ten stejný sektor, aby ho plánovač nemusel číst dvakrát, kdy bude hlava nejbllíž, zda mezitím "ten druhý" nedokončí současnou operaci, apod. Pochopitelně po celou tu dobu požadavek na čtení od přehrávače stagnuje, což pak způsobí zásek v přehrávání a to nechutné rozmazání obrazu kvůli chybějícímu klíčovému snímku v okamžiku zamrznutí.

Částečně to měl řešit low_latency tunable přidaný někdy kolem 2.6.32 (tak nějak), který mimojiné resetuje i zápisové NCQ operace, ale ten tu mám jako "1" defaultně a relativně beze změny.

Pokud se to v 2.6.37 nezlepší, asi zkusím BFQ, mám to v TODO listu už nějak dlouho.

[Ondrej 'SanTiago' Zajicek]

Závěrem snad jen to, že z group scheduling se stala mediální bublina - v běžném workloadu běžného desktop usera nepomůže prakticky vůbec.

Myslim, ze nikdy nebylo obecne tvrzeno, ze by group scheduling mel pomoci workloadu bezneho desktop usera. Jeho aplikace jsou uplne jine.

[trekker.dk]

2.6.24 si pamatuju - před ním boinc spotřebovával čas CPU jenom, když mu něco zbylo (takže nezdržoval ostatní aplikace). 2.6.24 a skupinový plánovač tohle změnily tak, že proces s nice 19 vždycky dostane aspoň něco (takže se cukal mplayer, enemy territory apod.)

Nicméně dobrá zpráva je, že se skupinové plánování dá vypnout a nic na tom nezávisí. ("Nejde přehrávat video, když dělám make -j16" mě fakt netrápí.)

[Luboš Doležel (Doli)]

2.6.24 si pamatuju - před ním boinc spotřebovával čas CPU jenom, když mu něco zbylo (takže nezdržoval ostatní aplikace).

K tomuhle by měla sloužit IDLE priority, bohužel na Linuxu vidím tohle jen u I/O. Fakt není nic takového na CPU?

[kralyk z abclinuxu]

Není tedy překvapením, že většina uživatelů „férovost“ vidí jinak; nebylo by hezké, kdyby překlad jako celek dostal 50% a přehrávání videa druhou polovinu?

No a ta zmíněná priorita procesu je na co?
Mi přijde, že tady by měl někdo Cimrmanovsky říct "Tudy ne, přátelé", protože geniální plánovač neexistuje a /dev/kristalova-koule taky ne.
Kdyby se nastavení priority nějak trochu líp zpřístupnilo uživatelům, bylo by to imho lepší pro všechny. Například by to mohlo být součástí WM, na štítku okna by mohly být tlačítka + / - nebo něco na ten způsob.

Schválně si otevřete seznam procesů. Pár daemonů si nastavilo míň, watchdog má realtime, ale jinak všechny uživatelský procesy maj obvykle stejně a nastavování není zrovna pohodlný... priorita akorát leží ladem. A přitom je to standard napříč systémy (v ostaních systémech mimochodem taky obvykle leží ladem).

[trekker.dk]

Mi přijde, že tady by měl někdo Cimrmanovsky říct "Tudy ne, přátelé"

Mě z článku přišlo, že se lidi snaží, ale Linusovi ruplo v kouli.

[Trained.Monkey]

Genialni planovac neexistuje mozna v Linusove stromu. Brain Fuck Scheduler od Con Kolivas je tomu ale hodne blizko.

[Ondrej 'SanTiago' Zajicek]

watchdog má realtime,

watchdogd s realtime prioritou? Dekuji nechci. To by totiz znamenalo, ze kdyz se ti tam neco zblazni a vytizi system takovym zpusobem, ze nic ostatniho nefunguje a nejde se tam prihlasit, tak watchdogd porad odpovida a system se nerestartuje.

[kralyk z abclinuxu]

... After finishing all tests watchdog goes to sleep for some time. The kernel drivers expects a write to the watchdog device every minute. Otherwise the system will be reset. As a default watchdog will sleep for only 10 seconds so it triggers the device early enough.

Under high system load watchdog might be swapped out of memory and may fail to make it back in in time. Under these circumstances the Linux kernel will reset the machine. To make sure you won't get unnecessary reboots make sure you have the variable realtime set to yes in the configuration file watchdog.conf. This adds real time support to watchdog: it will lock itself into memory and there should be no problem even under the highest of loads.

Also you can specify a maximal allowed load average. Once this load average is reached the system is rebooted. You may specify maximal load averages for 1 minute, 5 minutes or 15 minutes. The default values is to disable this test. Be careful not to set this parameter too low. To set a value less then the predefined minimal value of 2, you have to use the -f option. [zdroj]

i.e. zbláznění nějaké aplikace se nedetekuje neodpovídáním watchdoga, ale detekuje to přímo watchdog podle své konfigurace. Proto potřebuje RT prioritu.