Portál AbcLinuxu, 4. května 2024 20:51
Aktuální verze jádra. Citáty týdne: Alan Cox, David Miller. Souborový systém F2FS od Samsungu. Začleňovací okno 3.7, část druhá. Viditelnější zpracovávání RCU.
Začleňovací okno verze 3.7 je stále otevřené, takže nevyšlo žádné vývojové jádro. O novinkách začleněných za poslední týden se dočtete níže.
Stabilní aktualizace: stabilní jádro 3.2.31 vyšlo 10. října. Jádra 3.0.45, 3.4.13, 3.5.6 a 3.6.1 vyšla 7. října. Podpora řady 3.5 končí a vyjde asi už jen jedna aktualizace, takže byste měli naplánovat upgrade.
Pokud se podíváte na příspěvky do Linuxu, zjistíte, že přicházejí ze všech stran. Hlavní kód pro síťování napsali Rusové (a Alexey, který pracoval v jaderném výzkumném institutu, se na OLS dokonce objevil s 'gorilou', která v souladu se stereotypy dokázala pít vodku jako džus). Máme kód z vládních projektů, ze vzdělávacích projektů (některé z nich financuje stát), firem, dobrovolníků, od celé řady neziskových skupin. Dnes můžete nastartovat systém se síťovým kódem od Rusů a ethernetovým ovladačem od NSA.
-- Alan Cox
Kdykoliv patch projde více než 3 revizemi jen kvůli coding style, tak umře jednorožec.
-- David Miller
Během srpnové debaty o souborových systémech pro výměnná média se ukázalo, že za rohem čeká nový souborový systém. Nyní je jasné, že jím byl právě oznámený F2FS od Samsungu. F2FS je nový souborový systém důsledně navržený pro paměťová úložiště na bázi NAND flash. Používáme strukturu systému souborů v podobě logu, ale pokusili jsme se to přizpůsobit novému typu úložišť. Podrobnosti o tom, jak to funguje, najdete v příslušné dokumentaci.
Vnitřnostem f2fs se věnuje i Neil Brown na LWN.
V době psaní tohoto textu přetáhl Linus 9167 neslučovacích změn do hlavní řady; to je více než 3600 změn od přehledu z minulého týdne. Jak se očekávalo, přísun patchů se zpomalil a Linus si mezitím našel lepší zábavu. Přesto je to velmi živý vývojový cyklus.
Mezi změny viditelné uživatelům patří:
Mezi změny viditelné vývojářům jádra patří:
Pokud dostatečně dlouho provozujete linuxové jádro 3.6+, tak je pravděpodobné, že uvidíte proces pojmenovaný rcu_sched nebo rcu_preempt nebo dokonce rcu_bh, který spotřebovává dost procesorového času. Není divu, že se můžete divit, "co jsou ty procesy zač a proč žerou tolik CPU?"
Na „zač jsou“ je jednoduchá odpověď. Jde o nová jaderná vlákna, která ošetřují ochranné lhůty RCU, které dříve probíhaly v kontextu softirq. „Ochranná lhůta RCU“ je čas, po kterém všechny existující čtecí kritické sekce RCU dokončily svou práci, takže pokud modifikátor RCU odstraní položku ze struktury chráněné pomocí RCU a pak čeká po tuto ochrannou lhůtu, tak může dále bezpečně vykonat operace, které jsou pro uživatele dat destruktivní, například uvolnit položku. Tyto kritické sekce začínají na rcu_read_lock() a končí na rcu_read_unlock(). Modifikátoři mohou čekat po tuto ochrannou lhůtu pomocí synchronize_rcu(), nebo mohou naplánovat asynchronní spuštění funkce pomocí call_rcu(). Čtecí část RCU je extrémně rychlá a škálovatelná, takže to umí být užitečné tam, kde se hlavně čte.
Důvodem pro přesun ošetřování ochranné lhůty RCU do jaderného vlákna bylo zlepšení realtime latence (latence jak přerušení, tak plánování) na velkých systémech tím, že je umožněna preempce inicializace této ochranné lhůty. Bez preempce může initializace na velkých systémech způsobit latenci o více než 200 mikrosekundách. Mimo to tato změna také při současném zjednodušení kódu zlepší energetickou efektivitu RCU. Tato potenciální zjednodušení existují díky skutečnosti, že s jadernými vlákny je jednodušší zaručit pokračování v běhu, čímž se zabraňuje zásekům v případech, kdy všechna CPU spí a proto ignorují současnou ochrannou lhůtu, což potvrdil Paul Walmsley. Klíčovou věci je ale to, že tato jaderná vlákna nepředstavují novou režii. Místo toho je režie dříve schovaná za softirq nyní dobře viditelná.
Teď k tématu „proč žerou tolik CPU“, což je přesně ta otázka, jakou položil Ingo Molnar, jakmile u rcu_sched spatřil více než tři minuty času CPU po několika hodinách sestavování jader. Odpovědí je, že Linux využívá RCU opravdu aktivně, takže prostý hackbench po deset minut může mít za následek miliony ochranných lhůt RCU – a více než třicet sekund času CPU spotřebovaných v rcu_sched. To dělá okolo 30 mikrosekund na ochrannou lhůtu, což není přespříliš s ohledem na to, kolik práce tyto lhůty odvádějí.
Ukázalo se, že spotřeba CPU v rcu_sched, rcu_preempt a rcu_bh je často rovná souhrnu vláken softirqd.
Režie CPU na každé ochranné lhůtě je ale jen jednou stranou mince. RCU tvrdě pracuje na tom, aby zpracovávalo vícero aktualizací v rámci jedné lhůty. Není složité dosáhnout více než stovky aktualizací za jednu ochrannou lhůtu, což pak dělá režii jen cca. 300 nanosekund na aktualizaci a to není vůbec zlé. Navíc se objevily zátěže, kde jde dokonce o tisíce aktualizací za jednu ochrannou lhůtu.
Režie se pochopitelně může lišit a na tom závisí i režie na jednu aktualizaci. První věcí je to, že čím více CPU můžeme mít (při bootu určeno pomocí nr_cpu_ids), tím více práce musí RCU udělat při inicializaci a úklidu po ochranných lhůtách. Tato režie narůstá docela pomalu, extra práce je potřeba s každou skupinou 16 CPU, tato hodnota přitom závisí na parametru CONFIG_RCU_FANOUT_LEAF a také na bootovacím parametru rcutree.rcu_fanout_leaf.
Druhou věcí je to, že čím více CPU je nečinných, tím více práce musí RCU dělat při vynucování klidového stavu. Ano, čím zaneprázdněnější systém je, tím méně práce musí odvést RCU! Důvodem pro extra práci je to, že si RCU nemůže z důvodu úspory energie dovolit budit nečinná CPU. RCU tedy musí projít datové struktury pro každé CPU a přečíst informace o činnosti CPU, což pravděpodobně vyvolá cache miss.
Poslední věcí je to, že režie závisí na rychlosti CPU, výkonu paměti, režii virtualizace a tak dále. Na systémech, které používám, vidím režii mezi 15 a 100 mikrosekundami. Mám za to, že systém s tisíci CPU může potřebovat stovky mikrosekund – nebo dokonce milisekundy – na každou ochrannou lhůtu. Na druhou stranu může tento systém zvládnout velké množství aktualizací za jednu lhůtu.
Abychom si to shrnuli, rcu_sched, rcu_preempt a rcu_bh a režie s nimi spojená není nic, z čeho byste si měli dělat hlavu. Nejde o novou režii, ale o lepší vyjádření režie, která tu vždy byla.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.