Jaderné noviny – 7. 3. 2013: odstranění TINY_PREEMPT_RCU

25. 3. 2013 | Luboš Doležel | Jaderné noviny | 2924×

Aktuální verze jádra: 3.9-rc1. Závěr začleňovacího okna 3.9. Zjednodušení RCU.

Obsah

• Aktuální verze jádra: 3.9-rc1
• Závěr začleňovacího okna 3.9
• Zjednodušení RCU

Aktuální verze jádra: 3.9-rc1

Aktuální vývojová verze jádra je 3.9-rc1 vydaná 3. března. Linus k ní řekl: Nevím, jestli je to ve mně, ale toto začleňovací okno mělo více hrozivých momentů, než na co jsem zvyklý. Několikrát jsem přestal začleňovat, protože se objevily chyby, které vypadaly děsivě, ale lidé se na ně naštěstí vrhli jako paparazzi na Justina Biebera. Níže najdete přehled posledních věcí, které se do jádra 3.9 dostaly.

Stabilní aktualizace: verze 3.8.1, 3.4.34 a 3.0.67 vyšly 28. února; verze 3.8.2, 3.4.35 a 3.0.68 je následovaly 4. března. Verze 3.2.40 pak vyšla 6. března. Všechny obsahují obvyklý koktejl důležitých oprav. 4. března ještě vyšla verze 3.5.7.7.

Závěr začleňovacího okna 3.9

Do doby, než Linus vydal Linux 3.9-rc1 a uzavřel tak toto začleňovací okno, bylo přetaženo 10 265 neslučovacích změn. To je více než 2000 změn od souhrnu z minulého týdne. Mezi nejvýznamnější změny viditelné uživatelům patří:

• Řadič blokového I/O má úplnou podporu hierarchických řídících skupin.
• Kód NFS získal podporu jmenných prostorů, což umožňuje provoz NFS serverů v oddělených kontejnerech.
• Byl začleněn ovladač Intel PowerClamp; ten umožňuje omezování spotřeby CPU pomocí vkládání idle stavů.
• Device mapper se pyšní novinkou „dm-cache“, která může používat rychlý disk (jako třeba SSD) jako cache před pomalejšími zařízeními. Více v dokumentaci.
• Konečně byla začleněna podpora RAID 5 a 6 v systému souborů Btrfs.
• Kód pro defragmentaci souborů v Btrfs už podporuje snapshoty, takže defragmentace už nebude rozbíjet sdílení dat mezi snapshoty.
• Byla začleněna podpora architektur Synopsys ARC a ImgTec Meta.
• Podpora nového hardwaru.

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

• Konfigurační nástroj menuconfig má nyní tlačítka „save“ a „load“.
• Bylo začleněno přepracované API IDR, které zjednodušuje kód generující unikátní identifikátory. Kód v jádře byl náležitě upraven.
• Iterátor hlist_for_each_entry() přišel o nepoužívaný parametr pos.

Od této chvíle začala stabilizace jádra 3.9. Pokud budou věci probíhat jako obvykle, pak se konečné verze 3.9 dočkáme začátkem května.

Zjednodušení RCU

Read-copy update (RCU) je synchronizační mechanismus v linuxovém jádře, který umožňuje extrémně efektivní a škálovatelnou obsluhu dat, která jsou obvykle jen čtena. Ačkoliv je RCU docela efektivní, objevily se jisté obavy o jeho složitost.

Jedním ze zdrojů složitosti RCU je to, že jádro obsahuje rovnou čtyři implementace RCU, a to nepočítáme tři speciální odrůdy RCU (uspatelné RCU (SRCU), RCU-hh a RCU-sched popsané zde). Ty čtyři obyčejné implementace jsou vybírány jadernými volbami SMP a PREEMPT:

1. !SMP && !PREEMPT: TINY_RCU, které se používá na embedded systémech s málem paměti (desítky megabajtů).
2. !SMP && PREEMPT: TINY_PREEMPT_RCU pro systémy s malou pamětí a požadavkem na realtime odezvu hluboko pod jednotkami milisekund.
3. SMP && !PREEMPT: TREE_RCU, které se používá na serverových systémech pro vysoký výkon a škálovatelnost tam, kde je latence plánovače v řádu milisekund přijatelná.
4. SMP && PREEMPT: TREE_PREEMPT_RCU, které se používá na systémech, kde se vyžaduje vysoký výkon, škálovatelnost a odezva hluboko pod jednou milisekundou.

Smyslem techto čtyř implementací je pokrýt širokou paletu hardwarových konfigurací a zátěží, kde se Linux používá. Jenže i když se TINY_RCU, TREE_RCU a TREE_PREEMPT_RCU intenzivně používají tam, kde se to hodí, spotřeba paměti při TINY_PREEMPT_RCU není o moc menší než TREE_PREEMPT_RCU obzvláště, když se vezme v úvahu, jak PREEMPT samo o sobě zvyšuje spotřebu paměti v jádře. A všechna místa použití preempt_disable() a preempt_enable() generují skutečný kód.

Velikost při TREE_PREEMPT_RCU pro x86_64 je následující:

   text    data     bss     dec     hex filename
   1541     385       0    1926     786 /tmp/b/kernel/rcupdate.o
  18060    2787      24   20871    5187 /tmp/b/kernel/rcutree.o

Velikost pro TINY_PREEMPT_RCU je následujcí:

   text    data     bss     dec     hex filename
   1205     337       0    1542     606 /tmp/b/kernel/rcupdate.o
   3499     212       8    3719     e87 /tmp/b/kernel/rcutiny.o

Pokud máte opravdu málo paměti, tak použijete TINY_RCU:

   text    data     bss     dec     hex filename
    963     337       0    1300     514 /tmp/b/kernel/rcupdate.o
   1869      90       0    1959     7a7 /tmp/b/kernel/rcutiny.o

To nás vede k možnosti zbavit se TINY_PREEMPT_RCU, protože rozdíl ve velikosti není takový, aby mělo smysl jej ponechat.

Odstranění se samozřejmě musí udělat bezpečně a rozumně. Toto je navrhovaný postup:

1. Sesbírat námitky na LKML (hotovo: nejmenší systém s TINY_PREEMPT_RCU má 128 megabajtů paměti, takže rozdíl mezi TREE_PREEMPT_RCU a TINY_PREEMPT_RCU tvoří 0.01 % paměti).
2. Upravit Kconfig tak, aby TREE_PREEMPT_RCU bylo používáno i na systémech !SMP (v 3.9-rc1 nebo s tímto patchem).
3. Upozornit čtenáře LWN na tuto změnu.
4. Ponechat čas na testování a řešení případných problémů.
5. Pokud se žádné kritické problémy neobjeví, odstranit TINY_PREEMPT_RCU, což je naplánováno na verzi 3.11.

Pozor na to, že Linusův strom aktuálně opět umožňuje volbu implementace RCU při !SMP && PREEMPT: buď TINY_PREEMPT_RCU, nebo TREE_PREEMPT_RCU. Jde o přechodný stav pro případ, že by se nějaká chyba vynořila. Od verze 3.11 bude volba implementace RCU vynucena v souladu s pravidlem, že nemají být vidět zbytečné volby.

Pokud vše půjde podle plánu, pak tato změna odstraní z jádra přibližně 1000 řádek, což za to stojí. Takže jestliže používáte TINY_PREEMPT_RCU, vyzkoušejte TREE_PREEMPT_RCU na svém hardwaru a zátěži.

       

Komentáře

[Semo]

Ekvivalent PowerClampu som si pre nb napisal v bashi uz pred nejakym casom. Vetrak (dost hlucny) sa pusta, ak sa teplota zdvihne na 56C a vypina sa pri poklese na 51C. Takze skriptik sa pozera na teplotu CPU a ked dosiahne 54C, tak prepina cpufreq governor na powersave. A pri poklese na 53C zapina zase ondemand. (Horna hranica nie je 55C, pretoze sa obcas stavalo, ze uz to bolo prilis pozde a teplota dosiahla 56C a spustil sa vetrak.)

NB ma dost masivne medene chladenie (co poznat na hmotnosti) a dost veci dokaze uchladit cisto pasivne. Ale ked tam necham kompilovat velke mnozstvo Gentoo balikov (update raz za dlhy cas) a nechcem byt ruseny, tak po nejakom case (2h+) sa celkovo nahreje tak, ze uz teplota CPU prekroci 56C, a cely nb sa zase vychladi. Ale je to stale znacny rozdiel oproti vetraku zapinajucemu sa kazdych par desiatok sekund az jednotiek minut.

[victor8]

Obavam sa ze tebou popisane riesenie nie je ekvivalentom PowerClampu ani z rychlika.

Ty riesis len odvod uz vytvoreneho tepla (tym, ze zapnes vetrak), zatialco PowerClamp tomuto teplu zabranuje vzniknut (tym, ze vies nastavit maximum pre teplo, ktore CPU moze vyprodukovat).

[Semo]

Obavam sa, ze si si to vobec neprecital ani z rychlika.

Podla teploty prepinam governor a teda frekvenciu CPU, na ktorej bezi. Cim regulujem pocet vykonanych uzitocnych instrukcii za jednotku casu. Co je dost slusne priblizenie PowerClampu. (Vetrak je regulovany hardwareovo a jeho spustanie nejde ovplyvnit, riadi sa sam teplotou.)

[Jary]

Hloupost. Větrák neovládá. Přepíná governory.

Akorát si myslím, že by si měl místo přepínání governorů vyhrát s jejich nastavením. Myslím tam jsou nějaké thresholdy, které se dají různě šoupat.

[Sten]

PowerClamp sice používá podobné metody, ale funguje dost jinak: deterministicky limituje spotřebu a tím i celkem vzniklé teplo, protože to je důležité pro rozvodny a klimatizace. Teploty ani větráky procesorů jej nezajímají.