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

[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.