Jaderné noviny – 13. 10. 2012: Co jsou nová vlákna rcu_sched v jádře zač

30. 10. 2012 | Luboš Doležel | Jaderné noviny | 3033×

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.

Obsah

• 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

Aktuální verze jádra

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.

Citáty týdne: Alan Cox, David Miller

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

Souborový systém F2FS od Samsungu

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.

Začleňovací okno 3.7, část druhá

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ří:

• Jaderný načítač firmwaru se nyní bude snažit načítat soubory přímo z uživatelského prostoru bez účasti udevu. Cesta k firmwaru je nyní nastavena na několik alternativ pod /lib/firmware, je ale v plánu to učinit ohebnějším.
• Systémové volání epoll_ctl() nyní podporuje novou operaci EPOLL_CTL_DISABLE pro zakázání pollování na konkrétním popisovači.
• Xen je nyní podporován na ARM.
• Adresář tools nyní obsahuje nový nástroj „trace agent“; používá virtio pro efektivní přesouvání dat z hostovaného systému. Do tools byl přidán i acpidump, které umí vypsat obsah systémových tabulek ACPI do textového souboru.
• Nově je podporována online změna velikosti souborových systémů ext4, které používají skupiny metabloků (meta_bg) nebo 64bitová čísla bloků.
• Transakční vrstva UBI pro úložná zařízení na bázi flash paměti má novou experimentální funkci „fastmap“. Fastmap kešuje mapování erase bloků, což odstraňuje nutnost prohlížet celé zařízení při připojování.
• Souborový systém Btrfs získal schopnost vytvářet díry v souborech pomocí volání fallocate().
• Podpora různého nového hardwaru.

Mezi změny viditelné vývojářům jádra patří:

• Byly začleněny první části oddělení hlavičkových souborů pro API uživatelského prostoru. Ty vytvářejí adresáře include/uapi určené pro hlavičkové soubory obsahující definice datových typů viditelných z uživatelského prostoru. První díl patche míří do 3.7, zbytek se dostane až do 3.8.
• Základní části ovladače Nouveau pro čipsety NVIDIA byly přepsány. Vývojáři totiž rozumí tomuto hardwaru mnohem lépe než v době, kdy Nouveau začínalo. Při přepisu byly zohledněny tyto nové znalosti.
• Strom subsystému Video4Linux2 byl značně reorganizován; zdrojové soubory ovladačů jsou nyní tříděny podle typu sběrnice. Většina souborů byla přesunuta, takže vývojáři si budou muset zvyknout na nová umístění. Současně došlo k přepisu kódu DVB USB; řada ovladačů byla převedena na tento nový kód.
• ALSA má nové API pro správu zvukových kanálů; více v dokumentaci.
• Implementace červenočerných (RB) stromů byla značně přepracována. Nyní implementuje intervalové stromy i prioritní stromy; starší jaderná implementace „prio tree“ byla tímto nahrazena.

Viditelnější zpracovávání RCU

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.

       

Komentáře

[Mažňák]

21:50 a stále žádný opravář překlepů...? :)

[Honz]

Jedině tak Správkař kol...