Portál AbcLinuxu, 6. května 2025 20:45
Aktuální verze jádra: 2.6.37-rc1. Citáty týdne: Theo de Raadt, Linus Torvalds, Andrew Morton. Druhá polovina začleňovacího okna 2.6.37. Jaderný summit 2010: problémy s plánovačem.
Současné vývojové jádro je 2.6.37-rc1 vydané 1. listopadu. Začleňovací okno 2.6.37 je uzavřené. Je zde spousta změn – těsně pod 10k commitů od 2.6.36 – přestože začleňovací okno bylo trochu zkráceno. Příliš mnoho na to, abych je vypisoval. Za pozornost nicméně podle mě stojí to, že jsme se konečně zbavili BKL (big kernel lock) ve vnitřních částech jádra a můžete tak zkompilovat jádro bez podpory BKL. Cesta k tomu byla dlouhá; díky patří Arndovi a dalším, kdo se o to postarali. Všechny detaily lze nalézt v kompletním changelogu.
Stabilní aktualizace: 29. října vyšla jádra 2.6.27.55, 2.6.32.25 a 2.6.35.8; každé obsahuje dlouhý seznam důležitých oprav. Greg dal na vědomí, že pro jádro 2.6.35 vyjde ještě jedna aktualizace a pak podpora pro toto jádro skončí.
-- Theo de Raadt o IPv6
napsal Jonathan Corbet, 1 listopadu 2010
Byla vydána předverze 2.6.37-rc1, takže začleňovací okno je nyní uzavřené. Po shrnutí z minulého týdne bylo začleněno téměř 3100 sad změn; celkem bylo do 2.6.37 začleněno 9518 neslučovacích sad změn. Nejvýznamnější z nich viditelné pro uživatele:
Poslední významná bašta BKL – kód zamykání souborů – byla opravena. Nyní je možné přeložit obecně použitelné jádro bez BKL, i když ještě mnoho starších ovladačů ho stále potřebuje.
Byla přidána podpora pro protokol sdílené paměti CAIF.
Příkaz perf probe má nový parametr --vars, který vypíše seznam lokálních proměnných dostupných z místa, kde je umístěna sonda. S --externs jsou vypsány i globální proměnné. Nyní je možné vkládat sondy do nahrávatelných modulů.
Souborový systém ext4 má nyní podporu pro „línou inicializaci tabulky inodů“ [lazy inode table initialization], což je volba, která zrychluje vytvoření souborového systému. Ext4 také přichází s přepracovanou cestou zadávání I/O požadavků, která by měla zlepšit výkonnost a škálovatelnost.
„Zahazování v dávkách“ [batched discard] bylo přidáno v podobě ioctl() příkazu FITRIM. Tato vlastnost umožňuje souborovému systému informovat úložné zařízení pod sebou o všech nepoužívaných blocích naráz. Zatím je tato vlastnost implementována pouze v souborovém systému ext4.
Konečně byla začleněna tak dlouho odkládaná podpora pro Xen Dom0 (hypervizor). 2.6.37 stále nebude připraveno pro běh jako Dom0; k tomu bude potřeba ještě přinejmenším jeden vývojový cyklus. Kompletní plán vizte ve shrnutí od Jeremyho Fitzhardinge.
Subsystém fanotify byl znovu povolen a měl by být v 2.6.37 k dispozici.
Souborový systém 9p získal podporu pro POSIXové seznamy pro řízení přístupu [access control lists].
Do stromu staging byl začleněna jaderná čtečka obrazovky Speakup.
Mezi změny viditelné pro jaderné vývojáře patří:
Opět došlo k významným změnám v API ovladačů Video4Linux2. Nová vrstva „mediabus“ přidává flexibilitu potřebnou pro práci se složitými zařízeními, ale také poněkud komplikuje jednoduché ovladače. API videotext/teletext, které se dlouho nepoužívalo, bylo odstraněno.
Struktura file_system_type má nyní novou funkci mount(), která má nahradit get_sb().
Nyní začíná stabilizační období; konečné vydání 2.6.37 se téměř určitě objeví v lednu.
napsal Jonathan Corbet, 3 listopadu 2010
Google, jak všichni víme, nemá moc počítačů, které by si jen tak vysedávaly, takže není překvapením, že se firma snaží nacpat na každé dostupné CPU tolik práce, kolik je možné. To vede k míchání různých typů zátěže; jediný systém může pracovat na úloze o nízké prioritě, například na kódování videa, ale zároveň obsluhovat požadavky na vyhledávání o vysoké prioritě. Aby tyto zátěže fungovaly správně, používá se skupinové plánování [group scheduling]. Jak ale Paul Turner z Googlu poznamenal, skupinové plánování je „poměrně nevyspělé rozšíření“, které má několik zádrhelů.
Mezi ty patří fakt, že skupinové plánování shrnuje jak propustnost (množství času CPU vyhrazeného pro skupinu), tak prioritu do jediné hodnoty. Skupinové plánování má skutečné problémy se škálovatelností; konkrétně cesta probouzení je nákladná. Paul si stěžoval na chybějící API pro plánování. Správa skupinového plánování je složitá; v případě desktopu automatické seskupování podle tty zjednodušuje život, ale na serverových systémech nepomůže. Neexistuje žádná priorita mezi skupinami a žádná horní hranice toho, kolik může daná skupina zkonzumovat. Jsou problémy s vyvažováním zátěže, obzvláště když se na scéně objeví síťování. A v kontextu skupin neexistuje žádné plánování na základě nečinnosti ani dávkové plánování.
Co se týče vyvažování zátěže, Paul řekl, že vyvažování založené na váze má tendence poškodit využívání CPU. Vyvažování skupin je „primitivní“, což vede k „migracím stád“, které problému nepomohou. Skupinový plánovač nemá povědomí o NUMA. Také nebere v potaz čas CPU spotřebovaný obsluhou přerušení, což vede k posunutým výsledkům. Co se posledního problému týče, padl návrh použít obsluhu přerušení ve vláknech, která by tento problém mohla zmírnit.
Google chce použít SCHED_IDLE pro úlohy o nízké prioritě, ale to při vyvažování zátěže funguje mizerně. Vzhledem k tomu, že takové úlohy nemají žádnou váhu, plánovač je nepřesune na nečinné jádro. Takové úlohy také dostávají minimální podíl na CPU a i když je tento podíl malý, je stále příliš vysoký; není možné takové zátěže zcela izolovat od zbytku systému.
Co se škálovatelnosti týče, Paul upozornil na tg_shares_up(), která řeší distribuci šířky pásma CPU. Je drahá; vzhledem k tomu, že prochází celý Google cluster, pravděpodobně je to funkce, která spotřebovává nejvíce času CPU na světě. Je potřeba něco udělat, aby tato část systému byla usměrněna. Náklady na probuzení jsou také vysoké; Paul by rád našel způsob, jak přesunout část těchto nákladů na CPU, kde běží cílový proces. To by náklady rozprostřelo a omezilo soupeření o zámek mezi procesory.
Google zaslal několik patchů, které umožňuje specifikovat horní mez využívání CPU; Paul by byl rád, kdyby byly začleněny. Také by rád viděl, kdyby do skupinového plánování byly přidány priority. Hezké by také byly prostředky pro to, aby okno férovosti [fairness window] mohlo být pro každou skupinu jiné. Skupiny s vysokou prioritou by měly svůj podíl dostat v relativně krátkých periodách; práce o nízké prioritě naopak svůj podíl potřebuje jenom v delším období.
Paul také mluvil o další variantě plánování s časovým limitem [deadline scheduling] nazvané EEVDF. Pracuje s virtuálními časovými limity, takže není určeno pro běh v reálném čase. Umožňuje ale ten druh plánování, který Google potřebuje, a velmi dobře se hodí k současnému CFS plánovači. Evidentně poskytuje neuniformní periody latence – implementuje tedy proměnná okna, která by Google potřeboval – a má také hezké plánování úloh běžících při nečinnosti.
Poté se mluvilo o „kooperativním plánování“, které zahrnuje mechanismus, kterým by vlákna šlo informovat o tom, že jsou odstraňována preempcí nebo migrována. Tento notifikační mechanismus nebyl popsán jasně; znělo to jako varianta signálů. Také je zde potřeba pro mechanismus „nominace vlákna“, kde by jedno vlákno mohlo kdykoliv vybrat jiné, které by následně bylo spuštěno.
Přišla řeč i na testování, které, jak řekl Paul, je obtížné. Hodně pomohl linsched, simulátor plánovače, který byl nedávno opraven a zaslán Googlem. Linsched zjednodušuje spouštění testů snadno opakovatelným způsobem.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.