Jaderné noviny – 29. 10. 2014: Seznam přání pro jádro pro pracovní plochu

28. 11. 2014 | Tadeáš Pelech | Jaderné noviny | 3457×

Aktuální verze vývojového jádra: 3.18-rc2. Seznam přání pro jádro pro pracovní plochu

Obsah

• Aktuální verze vývojového jádra: 3.18-rc2
• Seznam přání pro jádro pro pracovní plochu

Aktuální verze vývojového jádra: 3.18-rc2

Aktuální vývojové jádro je 3.18-rc1, vydané 26. října (odkaz). Linus k tomu řekl:

Doufal jsem, že vydání rc1 způsobí, že se probere pár opozdilců a rychle všechno pošlou a zbytek rc pak bude probíhat normálně. Ale ne, celý týden se mi hrnuly žádosti o začlenění do hlavního stromu a rc2 je větší, než bych chtěl. Snad nejvýznamnější z těchto žádostí byl union systém souborů overlayfs, který byl nakonec začleněn po letech snažení.

Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace. Aktualizace verzí 3.17.2, 3.16.7, 3.14.23, a 3.10.59 byly v době vzniku tohoto textu v procesu kontroly, lze je očekávat nejdříve 30. října.

Seznam přání pro jádro pro pracovní plochu

Vývojář GNOME Bastien Nocera nedávno s e-mailovou diskusní skupinou jádra sdílel „seznam přání“, ve kterém navrhl celou řadu funkcí, které GNOME a další projekty prostředí pracovní plochy rády viděly v jádře přidané nebo rozšířené. V následné diskusi byly některé položky ze seznamu vyškrtnuty, ale mnoho ze zbývajících vyvolalo velkou diskusi, která by v průběhu času mohla vést k přidání nových funkcí do hlavního jádra.

Nocera zahájil svůj seznam tím, že GNOME i dříve vedl plodné diskuse s vývojáři jádra a že aktuální seznam se skládá z „položek, o kterých vývojáři jádra ani netuší, že bychom je chtěli využívat; nebo nevědí, že by se nám v případě začlenění hodily.“ Většina z těchto položek spadá do jedné ze dvou hlavních kategorií: řízení spotřeby a vlastnosti systému souborů. Najde se ale samozřejmě i dost dalších.

Nižší spotřeba

Pod řízením spotřeby Nocera uvedl nativní podporu hybridního pozastavení (na určitém hardwaru označováno jako Intel Rapid Start), podpora připojení v pohotovostním režimu, „implementace režimu spánku, která nepoužívá odkládací prostor,“ a několik menších položek (například zřízení jednotné sémantiky pro nastavení podsvícení obrazovky a lepší dokumentace pro správu napájení USB).

Hybridní pozastavení je funkce na úrovni firmwaru určená k minimalizaci času potřebného k obnovení systému z režimu spánku. Funguje tak, že nejdříve pozastaví systém do paměti RAM, ale pak po určitém čase zapíše obsah paměti na disk (přímo z firmwaru) a přejde do režimu hibernace. Před vypršením tohoto časového limitu probíhá probuzení velmi rychle, systém si navíc zachová svůj stav bez ohledu na to, jak dlouho je pozastaven. Matthew Garrett napsal opravu zavádějící podporu funkce v polovině roku 2013, ze které Nocera následně vytvořil požadavek na začlenění do hlavního stromu. Který ovšem nakonec uvízl na mrtvém bodě. Ozývaly se kritické připomínky, že funkce hybridního pozastavení Intelu bude nakonec nahrazena režimem připojení v pohotovostním režimu, novějším režimem napájení ve stavu nečinnosti, který umožňuje některým procesům na pozadí pokračovat v práci. Garrett také pracoval na přístupu k připojení v pohotovostním režimu.

John Stultz požadoval upřesnění jedné z dalších žádostí týkajících se řízení spotřeby: exportu příčiny události probuzení. Nocera to rozvedl – vysvětlil, že cílem bylo zjistit, zda zařízení probudil uživatel nebo hardwarová událost (např. alarm hodin v reálném čase), aby bylo možno adekvátně reagovat na různé situace. Citoval příklad použití v kódu uživatelského prostoru, který by zjišťoval a určoval, zda je vhodná doba ke spuštění dříve naplánovaného zálohování: pokud by uživatel probudil počítač otevřením víka notebooku, pravděpodobně by nebyla vhodná chvíle k zahájení zdlouhavého procesu zálohování. Pokud by šlo o automatické probuzení, zálohování by mohlo pokračovat.

Stultz, však namítl, že hlášení příčiny probuzení by nedokázal plně uspokojit všechny možné případy použití – zčásti proto, že druhů událostí probuzení mezi probuzením jádra a okamžikem, kdy se může spustit kód uživatelského prostoru, může být příliš mnoho (navíc, protože jsou asynchronní, by mohly dorazit v nepoužitelném pořadí). Ale ještě důležitější je (jak se zmínil Zygo Blaxnell), že to, která událost je nejnovější, je mnohem méně podstatné než to, zda (například) uživatel počítač právě používá; Což je možné zjistit jinými způsoby, například činností klávesnice. Alan Cox naopak podotkl, že v dlouhodobém horizontu většina předpokladů, které provázejí současné představy o stavech pozastavení, obnovení a hibernace, mohou zastarat:

• Žádné pozastavení ani obnovení nemusí existovat; je vhodné, aby se každý program choval slušně při probuzení, a co nejrychleji vracel zařízení a zdroje, které nepotřebuje.
• Zapnutí/vypnutí je extrémní, velmi výjimečná aktivita (funkčně odpovídá VAXům ze 70. let )
• Stavební model „blob s poklopem“ již nevyhovuje. Dokonce i zařízení klávesnice jsou čím dál častěji odpojitelná.

Otázky systému souborů

Druhá velká kategorie požadavků na funkce se týká funkcí systémů souborů a vrstvy VFS. Za prvé, Nocera oznámil, že inotify nesplňuje potřeby nástrojů plochy v různých otázkách. Výkon na velkých adresářových strukturách spotřebovává příliš mnoho zdrojů, oznámení o vytvoření souboru vyžaduje sledování celého adresáře a sledování událostí přejmenování a odstranění souborů je u velkých adresářů nákladné na zdroje. Tato omezení ovlivňují výkon indexování souborového systému, nástrojů pro zálohování a programů, které spravují „knihovny“ souborů (např. správci hudby a videa).

Sergej Davidoff z elementary OS dané téma rozvedl. Podle něj se vývojáři aplikací pracovní plochy snaží přejít ke koncepci knihoven souborů (jaká se používá ve správě hudby a videa) i v jiných typech aplikací. Podle něj je prezentace hierarchie souborového systému uživateli mnohem méně užitečná než inteligentní sledování příslušných souborů, které uživateli umožňuje vyhledávat je a pracovat s nimi na základě jejich metadat. fanotify, jak oba poznamenali, nenabízí správnou úroveň podrobností, například hlášení událostí přejmenovaní a přesunu.

Nocera také žádal o způsob šíření změn časového razítka v hierarchii adresářů směrem vzhůru. To znamená, pokud se změní soubor umístěný v adresáři /foo/bar/, bude existovat způsob, jak tuto změnu rozpoznat nejen u souboru samotného, ale také u adresářů /foo/bar a /foo. Dodal ale, že jednoduchá aktualizace času změny adresáře s daným souborem by bylo určitě špatným řešením, protože kvůli tomu by nejspíš přestalo fungovat mnoho programů.

Zkrátka, řekl, že programy v uživatelském prostoru by měly těžit z lepšího systému oznamování změn souborů – ideálně takového, který by události konsolidoval a sledoval adresářovou strukturu bez jejího pravidelného procházení. Uvedl, že kombinace zlepšení fanotify a přidání přichycení uživatelského prostoru by mohlo fungovat, stejně jako přidání funkcí protokolu změn, které jsou nyní k dispozici v Btrfs a XFS, do jiných systémů souborů.

Pavel Machek se zeptal, zda by nebylo možným řešením přidání (hypotetické) rekurzivní verze časového razítka mtime. Davidoff odpověděl skepticky, že by to fungovalo pro sledování online změn, ale že by mělo stačit sledování protokolu změn Btrfs „víceméně v reálném čase“. Sledování protokolu změn Btrfs za běhu by mohlo alespoň zajistit, aby vše provedla aspoň vyrovnávací paměť pevné velikosti, jako protiklad neohraničené paměti, kterou by pro stejnou úlohu vyžadovalo fanotify.

Různé

Nocerova poslední skupina položek seznamu přání je celkem všehochuť. Najdeme zde lepší uživatelské API pro průmyslové vstupně/výstupní (IIO) subsystémy použité pro různé snímače, pomocníka uživatelského pro ukončování procesů mimo paměť (OOM), systémové volání dotazující se, zda byly všechny procesy mimo řadu procesů ukončeny a varianta epoll_wait(), která přijímá absolutní čas místo časového limitu.

Podobně jako v případě ostatních kategorií, některé z těchto položek vyvolaly rychlé reakce. Patrik Lundquist navrhl, aby požadované funkčnosti epoll_wait() bylo možno dosáhnout pomocí timerfd(). Na to Nocera citoval původní zdroj požadavku, Ryana Lortieho, který řekl, že samostatné volání pro nastavení timerfd() ve všech instancích, kdy jádra přechází do režimu spánku, je náročné, a že "epoll obecně trpí tím, že je příliš upovídaný o systémových voláních, která musíte provést.“ Andy Lutomirski dodal, že realizoval dotazování procfs před několika lety a že je ochoten v této práci pokračovat, pokud to bude užitečné. Dotazování procfs by umožnilo uživateli otevřít sadu adresářů proc odpovídající zvolené sadě procesů a potom se dotázat adresářů, aby zjistil, zda nedošlo k nějakému ukončení.

Pokud jde o ostatní návrhy, zatím jsme se příliš reakci nedočkali. Z řady těchto položek ze seznamu jistě vykrystalizuje zavedení přívětivějších API uživatelského prostoru. Nocera k problémům IIO a hlášení událostí probuzení podotkl, že současné rozhraní prověřující neformátované soubory sysfs zdaleka nedostačuje.

Celkově však je komunita kolem jádra zjevně vnímavá na tyto potřeby projektů prostředí pracovní plochy. Na wiki stránce přání Nocera přirovnal cvičení „přání pro instalatéry“ odeslané vývojáři jádra Kayem Sieversem, Lennartem Poetteringem a Haraldem Hoyerem. Přístup přání pro instalatéry byl samozřejmě natolik úspěšný, že příslušní instalatéři to od té doby opakují. To vytváří dobré podmínky pro Nocerova přání pro pracovní plochu.

Je docela běžné slýchat o nové práci na jádře, která vychází jak z potřeb uživatelů špičkových datových center, tak tvůrci vestavěných systémů – možná prostě proto, že firmy v těchto oblastech podnikání mají sklon najímat vývojáře jádra. Proto je vždy dobré vidět, že komunita jádra stejnou měrou reaguje na potřeby vývojářů uživatelského prostoru pracujících v jiných oblastech, pokud se tito vývojáři rozhodnou své obavy vyslovit nahlas.

       

Komentáře

[Jendа]

ale pak po určitém čase zapíše obsah paměti na disk (přímo z firmwaru)

To je blbý, to určitě nepůjde šifrovat, že? Konečně jsme se dostali do stavu, že na uspaný notebook nejde provést coldboot, a oni to výrobci hned zkazí.

Lépe implementovat v HW jenom alarm, který po uplynutí toho intervalu systém probudí, a systém se zapíše do (šifrovaného) swapu sám.

Proč vůbec takovou věc dávat do firmware?

Otázky systému souborů

Uvítal bych FS-level verzování. Něco jako kdyby se vytvořil snapshot po každém zápisu souboru do určených adresářů. Už jsem si říkal, že si snad něco takového napíšu v userspace… Občas se mi stane, že něco omylem přepíšu, smažu atd.

[Heron]

Uvítal bych FS-level verzování. Něco jako kdyby se vytvořil snapshot po každém zápisu souboru do určených adresářů. Už jsem si říkal, že si snad něco takového napíšu v userspace… Občas se mi stane, že něco omylem přepíšu, smažu atd.

HAMMER?

Jinak i na obyč BTRFS by šlo dělat snapshoty třeba každou minutu. Není s tím nejmenší problém. Nápad: Při vhodné kombinaci se subvolume find-new by také šel získat seznam změněných souborů. (Jen nápad, nemám vyzkoušeno.)

[Jendа]

HAMMER?

Bohužel jsem vendor-locknutý na Linux.

Jinak i na obyč BTRFS by šlo dělat snapshoty třeba každou minutu.

Tomu jsem se chtěl vyhnout… Školní ZFS na větším množství snapshotů naprosto selhává.

root@archer:~# time zfs list -t snap|wc -l
2608

real	0m53.583s
user	0m0.212s
sys	0m2.860s

Navíc já to chci hned. Takže snapshot každou sekundu?

[Heron]

Btrfs není zfs (což platí i naopak), zde jsou snapshoty, stejně jako subvolume pro userspace k nerozeznání od adresářů a výpis adresářů je tak rychlý, jak rychle se stihne načíst adresářový záznam z disku. Než jsem se uklidnil, měl jsem přes 10 tisíc snapshotů 7 různých subvolumes a pohoda.

Jinak by mě docela zajímalo, k čem tuhle funkcionalitu požaduješ, když i jednou za minutu je málo. Pokud pominu, že každý editor nebo obecně programy umí funkci redo případně něco na ten způsob tak i kdyby ne, vrátit se o minutu zpět a třeba to udělat znovu, není takový problém. Ale rád se dozvím víc.

[Jendа]

Stává se mi, že pomocí mv, cp nebo > znova přepíšu soubor, který jsem před chvílí vytvořil. Nebo něco funguje, udělám změny, a pak to nefunguje, a chtěl bych si zobrazit diff. Realtime to chci proto, že udělat :wq, gcc, ./foo > sou<tab>bor.c, kurva zvládnu pod minutu.

10 tisíc snapshotů 7 různých subvolumes je pár dní při snapshotování každou minutu.

[Heron]

Mno, ehm git?

Nehledě na to, že stopro bude existovat plugin do vimu, který bude zachovávat historii úprav i přes několik spuštění, nebo stačí prostě jen změnit způsob práce na :w a ve druhém terminálu (druhém tabu screenu, split screen apod.) pokračovat gcc atd.

Na tohle buď zabere FS který bude snap opravdu po každém fsync (hammer), nebo vlastní udělátko na bázi inotify.

[Jendа]

Mno, ehm git?

Fakt nedělám commit po každé úpravě.

nebo vlastní udělátko na bázi inotify

Přesně takhle jsem to chtěl implementovat.

[koudy]

A co to dělat teda celé z vimu?

:w, :!gcc, :!./foo > soubor.c

Navíc to budete to mít v historii.

Ještě jednodušší by bylo udělat si makefile, protože vim umí skákat po chybách.

Úplně nejjednodušší mi přijde otevřít si 2 terminály, jak již navrhuje kolega níže/výše/někde. :)

 

(neberte to příliš vážně, bo VMS končí)

Pořiďte si VMS..., ten má tuto vlastnost implementovanou dosti geniálně (každá změna souboru se zapíše jako nová verze souboru, která se píše/psala jako jmeno.souboru;#verze )

[Heron]

:w, :!gcc, :!./foo > soubor.c

Přiznám se, že i když o této možnosti vím, tak jsem se to nikdy nenaučil dostatečně efektivně využívat. Naopak využívám screen a přeskakování mezi "taby" po každém :w. Za vrcholný úspěch ve vimu považuji namapování vlastních akcí na Fx klávesy, kam by se dal umístit i onen :w a !git něco (nebo při dostatečném šílenství i !btrfs sub snap ....

[koudy]

Jj souhlas, není to na běžnou práci.

To bylo spíše "jaké další možnosti máte" než že bych čekal že se tím budete řídit :)

Namapování kláves není špatný nápad, to si budu muset taky nastavit, díky za radu :)

Ještě že je vimrc, to mám asi 3x zazálohované, protože bych to zas dával půl roku do kupy...

Ten ":make" je docela šikovná věc, na menší projekty doporučuju.

Screen moc nepoužívám zase já, i když na jednoduché porovnání není nic lepšího.

[Jendа]

Pořiďte si VMS..., ten má tuto vlastnost implementovanou dosti geniálně (každá změna souboru se zapíše jako nová verze souboru, která se píše/psala jako jmeno.souboru;#verze )

Ano, přesně takhle to má vypadat (a přesně takhle jsem se to dočetl v UNIX Hater's Handbook z roku 1990). Žádné generování FS-wide snapshotů v době, kdy se třeba nic nezměnilo…

[Heron]

Jenomže ono každé pro má své proti. Kdyby se po každé změně (asi tedy po každém fsync souboru) vytvořila nová verze, tak by jsi měl cca 100 verzí souborů za 1s. (Dejme tomu o binárních logů databázových systémů či journalů já nevím třeba sqlite). To by asi nešlo,co.

Takže by se musel vytvořit systém na označení, které soubory chci a které nechci verzovat. Nastala by dlouhá diskuse, zda má být default verzování zapnuté či vypnuté. (Kdyby to bylo default zapnuté, přišlo by se o výkon, kdyby to bylo vypnuté, lidé by nadávali, že to zapomínají zapnout.)

Dále by musel být systém na odstraňování starých verzí. Bez něj by dříve nebo později na daném FS došlo místo. A opět by se našli kritici tohoto systému, protože jim automaticky smazal verze, které hrozně potřebují.

Atd.

Přijde mi lepší mít k diposici komponenty, se kterými si totéž mohu zrealizovat. Těch tříd komponent je více, na každou činnost se hodí jiná. Na něco zrovna ten git, na něco jiného třeba btrfs snap na něco ještě dalšího třeba inotify a triggrovat si akci dle potřeby.

[koudy]

Ten FS na VMS byl především na textové soubory - každý řádek souboru se ukládal zvlášť a ještě navíc bez znaku nový řádek.

 

Nešlo by udělat něco jako příznak "?změnil se soubor?" a podle toho ne/od-zálohovat soubor?

V ideálním případě by se to propagovalo do nadřazených adresářů.

Tím by se asi dost snížilo zatížení disku. (teď tady jen tak házím myšlenkama, určitě se nad tím někdo zamyslel líp a je to vyřešený rozumnějc než to navrhuju já)

 

Nebyla by hloupost dávat žurnál na takovýto disk? Nebo téměř cokoli co se rychle mění - dát tam DB je už úplně asi mimo ne? (sqllite neberu jako DB)

Rozuměl bych podobný FS například na HOME adresářích, nějaké sdílené adresáře a třeba i /etc a www stránky, ale na jiná použití?

[Heron]

Nebyla by hloupost dávat žurnál na takovýto disk? Nebo téměř cokoli co se rychle mění - dát tam DB je už úplně asi mimo ne? (sqllite neberu jako DB)

Byla. Jenže doba, kdy každý OS měl jen v minimálním základu 8 FS (ne-připojené s různými volbami jako ro, noexec apod.) je zdá se dávno pryč. To byla také doba, kdy si databáze sami spravovaly vlastní blokové zařízení a neběžely nad FS. Jenže ta doba je pryč. Pro něco je to špatně, pro něco je to dobře. Mě se sjednocování různých částí adresářového stromu pod jeden FS obecně nelíbí, protože ten proces je někdy dělán dost živelně. (Jako že když máte oddělený /usr tak třeba nenabootujete, protože autor jistého initu nepovažuje oddělený usr za dobrý nápad a proto ho všem zakáže.)

Rozuměl bych podobný FS například na HOME adresářích, nějaké sdílené adresáře a třeba i /etc a www stránky, ale na jiná použití?

Vzhledem k tomu, že kde co dneska používá služeb souborových databází (a nikoliv třeba systémové databáze třeba na vlastním blokovém zařízení), tak ona potíž se 100 verzemi za 1s vám klidně vznikne i na /home. Je ve FF je 16 sqlite databází i se svým žurnálem.

[XX]

Staci si uvedomit, ze snapshot z 13:57:42 z minuleho patku nepotrebujes. Chci tim rict, ze je dobre mit caste snapshoty pro nova data a jak starnou, tak je redit. Neco jako:

1 minutove 1..5

10 minutove 1..5

1 hodinove 1..x

1 denni 1..y

(tydenni, mesicni..)

Tj. potreboval bys 5+5+x+y snapshotu, coz tak moc neni, ale je to jen ukazka.

Je to vic skriptovani, ale vyplati se. Neco podobne nam beha v praci pres rsync, cele to pousti cron:

Denne: posledny denni (y) se maze.

Kazdou hod: posledny 1hodinovy (x) se maze, ale jednou denne rotuje na prvni denni (1).

Kazdych 10min: posledny 10minutovy (5) se maze, ale kazdnou hodinu rotuje na prvni 1hod (1).

Kazdou minutu: poridis novy snapshot, a posledny 1minutovy (5) se maze, ale kazdych 10min rotuje na prvni 10min(1).

Snad jsem to moc nezkomplikoval.

Predstavivosti se meze nekladou.

[ncweohfnow]

Nerad Vam kazim skumanie ako vymysliet nove koleso, ale s radostou pouzivam nilfs (https://en.wikipedia.org/wiki/NILFS) uz dlhsiu dobu pre uctovnisky SW. Clovek nikdy nevie, ktoru sekundu mu zacne nejaky windows cervik sifrovat data na disku a podobne. Spomenuty FS riesi "snapshootovanie" po kazdom zapise na disk. Mal som potrebu zatial iba raz zachranit zmazany subor a bola to otazka 10 minut citania a 2 minuty pisania. Pekne.

PS: Spomenuty FS pouzivam IBA na particii s 5 GB datami na oddieli cca 10 GB, kde je uctovnicky SW, par naskenovanych dokumentova a podobne somariny, ktore sa pouzivaju vyhradne z windows PC, pristupne cez sambu (a pripadne z virtualu). Nemyslim, ze by spomenuty FS bol vhodny na 2TB zbierku dat...

[ed]

myslim, ze v tomto ohlade mlatite uplne nespravneho slameneho panaka a problem existuje medzi klavesnicou a stolickou.

bez zavedenia dodatocneho API nema filesystem ako poznat, ze (automaticky) vytvoreny snapshot suboru je nejakym psosobom vnutorne konzistentny. iste mozno namietat, ze ak sa zavre popisovac, aplikacia so suborom skoncila, lenze linux na rozdiel od widiel neforcuje ziadne zamky, takze na jeden subor moze byt otvorenych niekolko popisovacov naraz a mozu existovat cinnosti pri ktorych aplikacia popisovac uzavrie aj medzi zapismi, kedy subor necha v (pre aplikaciu) inkonzistentnom stave.

to je mimo ine aj dovod, preco (aspon pokial som sledoval) filesystemy neskusaju nejako agresivne zurnalovat samotne data. jednak to chce strasne velky priestor v zurnale a za druhe (co je dolezitejsie) je to vacsinou zbytocne, pretoze v pripade padu to aj tak konzistenciu dat nejako dramaticky nezlepsi (minimalne nie dost na to, aby sa oplatilo plytvat na zurnalovanie dat vykonom bez dodatocneho API).

[anonym]

presne vim na cem to ti bezi, a takovemuhle "vykonu" bych se nedivil (hint: beta)

pro vypis se prochazi spojak (vytvoreni rovnou vrazi novy prvek na zacatek, takze no problem), ktery je rozesety v malych blocich po vsech diskach (v tvem pripade hlavne po tretine, protoze to vzdycky je mensi jak 1 blok, a raidz2 k tomu prida 2 pro paritu, takze mas celkem 3 bloky, coz deli tvuj pocet disku).

ZFS je optimalizovane na to aby se snapshoty primarne vytvarely v O(1), sekundarne mazaly v O(1) (plus minus, najit snapshot je porad O(n) vuci poctu snapshotu na datasetu). vypis vsech snapshotu podle nich neni uplne casta operace

[Jendа]

(hint: beta)

iftop si myslí, že to brzdí seeky, ne linka. A tam si polem nepomůžeš… Odpovídá to nějakým 50 seekům za sekundu, což je běžná rychlost 7k2 disku.

[anonym]

nemluvil sem o lince ale spis o tom radici toho 'pole' (linka ti bude vadit pri scrub/resilver)

bohuzel nemam zadny takhle velky system s direct-attached disky, abych to vyzkousel, ale v teorii by to melo jit #seeku na disk * #disku

ale obecne ano, vypis snapshotu v ZFS je random IO-heavy operace, vytvareni (a mazani, jakmile si ho nasel) neni

[petr_p]

Uvítal bych FS-level verzování.

Nemůžu si s úšklebkem nevzpomenout na v článku zesměšňovaný VMS :D

[Michal Kubeček]

Neodpustím si tradiční WtF-list:

"Stolní počítače"??? Opravdu je nezbytné vymýšlet krkolomné české verze úplně všech zavedených pojmů? Nemluvě o nekonzistenci, protože později už desktop (z hlediska kontextu IMHO mnohem vhodněji) překládáte jako pracovní plochu nebo prostředí.

„přání pro instalatéry“ adresované vývojářům jádra Kayi Sieversovi, Lennartu Poetteringovi a Haraldu Hoyerovi.

Je tam "by", takže ti tři jsou autoři, ne adresáti, a ta jména tedy nemají být ve třetím pádu ale v sedmém.

[Tadeáš Pelech]

Stolní počítače je normální výraz, nevymyslel jsem si ho já, ale v tomto konkrétním kontextu se opravdu nehodí.
Díky za obě upozornění, upraveno.

[Filip Jirsák]

Mě tedy nejvíc zaujal pomocník uživatelský a procesy mimo paměť:

pomocníka uživatelského pro ukončování procesů mimo paměť (OOM)

Co takhle "pomocníka v uživatelském prostoru pro ukončování procesů při nedostatku paměti"?

[lertimir]

Je zajímavé, že mezi požadavky není prioritizace procesů, které patří oknu s fokusem oproti backgroundu. Pro reakci systému by to mohlo mít pozitivní vliv.

[Jendа]

To snad není věc kernelu. Stačí, aby window manager nastavoval nice.

Bohužel v dnešní době na desktopu není bottleneck CPU ale I/O a v tom Linux naprosto selhává (zejména kvůli mizerně implementované cache) a žádný nice/ionice tomu nepomůže.

[lertimir]

Asi máš pravdu, ale možná analýzy k tomu, jestli by pro desktopy nebyl vhodný jiný scheduler, by mohly být. Přece jen shedulery jsou prostavené spíše pro serverové zátěžě. A optimalizace pro I/O je samozřejmě další závažna otázka.

[Nicky726]

To snad ale existuje, plánovač vyvíjený speciálně pro desktop užití: BFS.

[Jendа]

Já teda potkával hlavně ten problém, že když jsem dal kopírovat velký soubor, tak mi to vylilo cache všech ostatních aplikací…

[lertimir]

Já potkávám 2-3 typické problémy.

1. Kopirování velkých souborů na pomalejší zařízení blokuje celý stroj. I přes výrazné snížení parametru podle jaderných novin se to pořád někdy kouše.
2. Snížení response systému při dávkových zpracováních fotek v desktopu. Např. po doladění RAW operací zpracování 200 fotek z RAW do jpg/png
3. Podobně jako 2 překodování nebo jiné zpracování videa v backgroundu.

V žádném z těchto případů třeba nejde efektivně si pustit vedle toho video a mít ho bez lagů, nebo třeba pracovat v digikamu v foregroundu a mít ho výkonný. (na 4jádru i5 na 3,8GHz)

Považoval bych za rozumné, když by na desktopu bylo možné systém nastavit tak, aby front aplikace (okno s fokusem) měla vše, co potřebuje, a ostatní nesystémové aplikace (samozřejmě systémové aplikace jako operace se swapem, ntp server ap. by byly ještě prioritnější), aby dostaly zdroje až když je front aplikace nepotřebuje. (alespoň v praktickém slova smyslu "vše", např., když zdroj potřebuje jak front aplikace, tak něco běžící v pozadí, tak to "vše" neznamená nekonečno:0, ale řekněme 98:2 nebo 95:5, ale také ne 50:50, jak je to často teď. A také tím nemyslím, že CFQ nebo jiné rovnoprávné postupy by se měly rušit, jen to, že možnosti silné prioritizatice procesu v popředí nejsou.

[Heron]

V žádném z těchto případů třeba nejde efektivně si pustit vedle toho video a mít ho bez lagů, nebo třeba pracovat v digikamu v foregroundu a mít ho výkonný.

Toto tedy nepozoruji. Konvertoval jsem 290 GB videí do menšího rozlišení (hlavně pro menší objem pro mobilní zařízení) v HandBrake, nacpal jsem frontu, nastavil minimální prio (nice 19) a normálně pokračoval v práci včetně přehrávání kde čeho a hraní minecraftu. Kdybych neslyšel ventilátor ve zdroji tak ani nevím, že počítač něco dělá. (AMD FX 8350)

(Potom jsem teda usoudil, že video vlastně ani nepotřebuju a vytáhl jsem z toho jen zvuk a ten převedl do schůdnějšího formátu pro starý hloupý nokia mobil. Opět, hromada ffmpegů, nice 19 a věnoval jsem se něčemu jinému.)

[lertimir]

To asi máš pravdu. Jednoduchý úkon realizovaný třeba ffmpeg s nastaveným nice je OK. To co OK není, je když máš třeba 50 záběrů, mezi nimi máš v kdenlive nastavené nějaké přechody, nebo navíc vyrobené animace třeba v blenderu, vše je v podstatě video ve formátu několika konkrétních kamer, většina ve fullHD a pár záběrů třeba v nižším rozlišením, ty máš nadefinované, střihy, přechody a animace, specifikuješ výstupní formát a v tom kdenlive to pustíš. A víš, že ta hodina filmu bude 3 hodiny výpočtů, ale to co vadí, že ty 3 hodiny je počítač těžce použitelný. Když bych mohl normálně pracovat (nebo se třeba bavit), a zpozdil se výpočet na 4 hodiny tak OK.

Je možné, že hlavní vina je v kdenlive, že by mohli pouštět jednotlivé volání s nice a nedělají to. A také nerozporuji, že mnohé případy lze vyřešit příkazy z bashe s nastaveným nice/ionice. Ale stojím si za tím, že v desktopu se řeší jiná optimalizační úloha, nejde o férové rozdělení výkonu/io mezi procesy, ale o prioritu toho, co uživatel v konkrétním okamžiku požaduje.

[Heron]

Asi to z mého komentáře nebylo patrné, ale HandBrake (automaticky) používá všecha dostupná jádra (v tomto případě 8), stejně tak těch ffmpegů bylo 9 (používám make -j "počet cpu+1"). Celé tohleto běželo víc než 24h.

Ale stojím si za tím, že v desktopu se řeší jiná optimalizační úloha, nejde o férové rozdělení výkonu/io mezi procesy, ale o prioritu toho, co uživatel v konkrétním okamžiku požaduje.

Chápu, že někteří uživatelé mohou takovou funkcionalitu požadovat a nemám nic proti tomu, aby to tak šlo nastavit. Já bych si to nezapnul.

je počítač těžce použitelný

Co to konkrétně znamená? Pokud vezmu za příklad osmijádro, zcela nefunčkní prioritizaci a dejme tomu 9 procesů (8 na převod videa a devátý nějaký uživatelský), tak pořád na onen uživatelský proces zbývá 88% "jednoho jádra" (nebo 11% celého CPU, jak chceme). To přece není málo a na hromadu úloh, co se běžně na PC dělají to bude zcela dostačující (a to včetně přehrávání videí). Pokud je počítač "těžce použitelný" patrně to bude mít jinou příčinu, než zrovna prioritizaci procesů.

[lertimir]

... (používám make -j "počet cpu+1"). Celé tohleto běželo víc než 24h.

Ale stojím si za tím, že v desktopu se řeší jiná optimalizační úloha, nejde o férové rozdělení výkonu/io mezi procesy, ale o prioritu toho, co uživatel v konkrétním okamžiku požaduje.

Chápu, že někteří uživatelé mohou takovou funkcionalitu požadovat a nemám nic proti tomu, aby to tak šlo nastavit. Já bych si to nezapnul.

Zajímalo by mne, proč bys to nezapnul? Chápu, že zkušený informatik nebo systémový správce serverů se i k svému desktopu chová se znalostí procesů na serveru, a v argumentaci právě toto demostruješ. Na druhou stranu linuxový desktop používá i dost lidí, kteří o procesech nice, make -j ap. nemají ani tuchu. Pokud Linus má zájem o vyšší rozšíření desktopu, tak aby jej používalo čím dále více lidí, budou spíše z kategorie BFU, než ze správců serverů. V mém okolí je cca 10 lidí s linuxovým desktopem (část i díky mně) kteří s informatikou nemají nic společného, někteří z nich za léta používání ani nespustili terminálové okno, jiní jej používají jen na specializovanou akci (jako dcera bioložka v něm spouší statistiku v R-ku pokusů a nic více).

Pokud nový uživatel bude v situaci, kdy přijde kamarád s tím, že: "Ještě mi nakopiruj tady těch pár videí a alb na flešku. A než to dojede, tak bych se podíval na mail, kde přesně ten mejdan máme. Jaktože ti to nefunguje!? Vždyť to nic nedělá!? Co to máš za systém!?!!" Toho pak znalosti o zaplnění "dirty pages" zajímat nebudou. Bude ho zajímat, že systém reaguje nebo ne.

To, že systém v rozumném čase (100-300ms) zareaguje vždy (kromě naprosto nezbytných systémových událostí, jako třeba to, že chci pustit proces, který je dávno odswapovaný a musí se natáhnout) je podle mne pro široce akceptovatelný desktop nutností. (Dirty pages k tomu nutnému nepatří, protože tak, jak to vnímám, je že návrh správy stánek má někde v pozadí nevyslovené očekávání podobných přenosových rychlostí u všech blokových zařízení. A to nyní velmi neplatí. Od SSD s rychlostmi cca 400MB/s přes rotační disky s cca 100 MB až k pomalým flaskám a SD kartám s rychlostí i cca 4MB je 100:1 poměr. A mnohdy se na pomalá zařízení přesouvají velké objemy dat. A práce s stránkami by měla vědět jaké to zařízení fakticky je.) A jedna z vlastností, která by rychlost reakce systému podporovala, je to, aby front okno dostalo všechny zdroje (CPU/IO/GPU), které potřebuje do nějakého rozumného limitu (třeba 80-90%).

Už třeba to, že mnohdy při psaní textu se písmeno objeví s 0,5 s zpožděním, snižuje komfort. Pro toho kdo píše rychle, tak mnohdy píše po skupinkách. Přitom z hlediska celkové spotřeby času mezi procesy je jedno, jestli se zapíše ihned díky prioritě foregroudu, nebo až po prodlevě, kdy ho předběhl jiný proces. Ale pro uživatele to jedno není.

Ale i když o tom píši kriticky, nemyslím si, že linuxový desktop je na tom nějak strašně, jen má některé vlastnosti, na nichž by bylo záhodno pracovat. A také chápu, že ta prioritizace má mnohá úskalí, dost si pamatuji, když jsem na winXP, které je velmi postavené na prioritizaci foregroundu, spustil nějaký delší výpočetní proces, odešel od kompu, na systému se automaticky spustil spořič obrazovky, který tím pádem jel ve foregroundu a výkon si vzalo počítání pitomých křivek a neměl ho proces, který jsem potřeboval.

[Michal Kubeček]

Pozor, některé desktopové distribuce mají dnes defaultně zapnuté kernel.sched_autogroup_enabled, což v podstatě znefunkční niceness.

[nyan]

1. Kopirování velkých souborů na pomalejší zařízení blokuje celý stroj. I přes výrazné snížení parametru podle jaderných novin se to pořád někdy kouše.

Bohuzel, tohle me taky stve, a uz pekne dlouho...

[Heron]

To je podle mě očekávané chování. Cache se zkrátka použije na něco aktuálnějšího a stará data se vylijí. Naopak bych se velmi podivil, kdybych po zkopírování nějakého souboru a následující práce s ním zjistil, že se opět čte zbytečně z disku.

[Hans1024]

LRU je jen jeden z moznych pristupu a ne vzdy je vhodny. Je prakticky jedno, jestli se z 10GB kopirovaneho souboru nacachuje 4GB, nebo jen 3.9GB. Kdyz se kvuli tem 100MB navic vyhazi z pameti vsechny konfiguraky a jine mensi soubory vsech aplikaci v systemu (a to jenom proto, ze k nim par sekund nepristupovaly), clovek se nestaci divit, jak se to najednou trha.

[nyan]

Trosku neocekavane ale je, kdyz jsou v te same cache mmap()nute stranky kniznic a spousteneho kodu (a proti datum nejsou nijak prioritizovane). Takze ti kopirovani velkeho souboru vesele vylije z cache 80% spustitelneho kodu desktopu...

[petr_p]

Zrovna v dnešním desktopu, kde na každou kravinu se používá D-Bus, by tento přístup měl katastrofické důsledky.

[pet]

Takže když něco déletrvajícího v jednom okně spustím a mezitím co na to čekám tak se přepnu do jiného okna tak to abych čekal ještě déle? No to snad ne!!

[lertimir]

No to by záleželo, co v tom okně děláš. Zpozdilo by se to jen o to, co bys mu v tom druhém okně sebral na zdrojích. Tak je to i teď, jen díky čekání v tom front okně tomu sebereš méně.