Jaderné noviny – 11. 7. 2013: Další redukce tiku v jádře

29. 7. 2013 | Luboš Doležel | Jaderné noviny | 4222×

Aktuální verze jádra. Citáty týdne: Arnd Bergmann, Dave Chinner, Thomas Gleixner. Začleňovací okno řady 3.11, část druhá. Je celý systém nečinný?.

Obsah

• Aktuální verze jádra
• Citáty týdne: Arnd Bergmann, Dave Chinner, Thomas Gleixner
• Začleňovací okno řady 3.11, část druhá
• Je celý systém nečinný?

Aktuální verze jádra

Začleňovací okno verze 3.11 zůstává otevřené. Přehled toho, co bylo za poslední týden začleněno, najdete níže.

Stabilní aktualizace: verze 3.8.13.4 vyšla 3. července, verze 3.6.11.6 vyšla 9. července a verze 3.5.7.16 5. července.

Citáty týdne: Arnd Bergmann, Dave Chinner, Thomas Gleixner

Když ti zkušení vývojáři řeknou, že se mýlíš, tak se musíš pokusit pochopit, v čem chyba spočívá, aby ses z ní ponaučil a neopakoval ji. Pokud děláš stejné chyby dokola, tak se správci naštvou a budou tě ignorovat (nebo ještě hůř), což není moc dobrá situace, pokud chceš, aby tvé patche byly začleněny.

-- Arnd Bergmann

Škálovatelnost už není něco, co by se řešilo až dodatečně – nové funkce systémů souborů a jádra se musí s ohledem na škálovatelnost navrhovat od počátku. Žijeme ve světě, kde i telefony mají 4 jádra procesoru.

-- Dave Chinner

Copy-paste je ale příhodná věc, co? Jen by to mělo mít popup, který by se ukázal při druhém kopírování té samé věci a dotázal se, jestli ses nad tím opravdu zamyslel.

-- Thomas Gleixner

Začleňovací okno řady 3.11, část druhá

V době psaní tohoto textu Linus přetáhl 8275 neslučovacích změn do hlavní řady pro vývojový cyklus 3.11. Hodně z toho jsou opět interní vylepšení a pročištění bez přímého dopadu na uživatele jádra. I tak se ale od posledního přehledu našla řada zajímavých věcí.

Mezi významnější změny viditelné uživatelům patří:

• Přibyl nový mechanismus „soft dirty“, který může být použit uživatelským prostorem ke sledování stránek, do kterých proces zapisoval. Je určený pro kontrolní bod/restart v uživatelském prostoru, ale může najít i další využití; více najdete v dokumentaci.
• Bezpečnostní modul Smack nyní funguje s protokolem IPv6.
• Mechanismus socketů ICMP má podporu pingu přes IPv6.
• Systémové volání ptrace() má dvě nové operace (PTRACE_GETSIGMASK a PTRACE_SETSIGMASK) pro získání a nastavení masky blokovaných signálů.
• 64bitové PowerPC stroje mohou nyní využívat funkčnost transparentních velkých stránek.
• Jaderná implementace klienta NFS nyní podporuje protokol NFS ve verzi 4.2. Navíc je podporované značkované NFS (Labeled NFS), které umožňuje používání mandatorního řízení přístupu [mandatory access control] na systémech souborů NFSv4.
• Jádro podporuje kompresi LZ4, jak v kryptografickém API, tak pro kompresi binárky jádra.
• Byla začleněna dynamická správa výkonu pro většinu grafických čipů AMD Radeon (řada r600 a všechny následující). Jde o spoustu kódu a stále je považován za experimentální, takže je prozatím ve výchozím nastavení zakázán; argument radeon.dpm=1 na příkazové řádce jádra tuto funkci zapne, pokud chcete pomoci s laděním.
• Po zaškobrtnutí na poslední chvíli byly začleněny patche pro pollování sítě s nízkou latencí.
• Subsystém Open vSwitch nyní podporuje tunelování a protokol GRE.
• Podpora nového hardwaru.

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

• Dvě nová zpětná volání – offline() a online() – byla přidána na úrovni řadiče. offline() bude zavoláno v moment, kdy má zařízení být odpojeno za běhu; mělo by být ověřeno, jestli může zařízení být odpojeno, ale ještě by nemělo být vypnuto. Pokud by odpojení bylo zrušeno, pak je zavoláno online() pro opětovné spuštění zařízení. Účelem volání je se ujistit, že je možné odpojení za běhu provést dříve, než se začne doopravdy uskutečňovat.
• Nástroj checkpatch má novou, experimentální volbu --fix, která se automaticky pokudí opravit řadu jednoduchých problémů s formátováním.

Je celý systém nečinný?

Funkce úplného dynamického tiku, která se objevila v jádře 3.10, může dobře posloužit uživatelům, kteří chtějí, aby jejich aplikace mohly naplno využít jedno nebo více CPU bez zásahů jádra. Odstraněním tiku se minimalizuje režie jádra a případná latence. Běh s plně dynamickým tikem má bohužel ale potenciál zvýšit spotřebu energie. Na vyřešení problému se pracuje, ale ukazuje se, že je pro to nutná informace, kterou je obtížné získat: je systém úplně v klidu, nebo ne?

Jádro má schopnost vypnout pravidelná přerušení hodin na nečinných procesorech už po mnoho let. Každý procesor, který se stane nečinným, si zkrátka vypne tik hodin; jakmile jsou všechny procesory nečinné, pak bude tik zakázán všude. Plně dynamický tik – kdy je tik možné zakázat na aktivních CPU – ale situaci komplikuje. Zatímco většina procesorů (za správných okolností) dokáže běžet bez tiku hodin, jeden procesor musí nadále mít tik povolený, aby bylo možné provádět řadu důležitých operací souvisejících s počítáním (účtováním) času. Je jasné, že toto poslední CPU by mělo být schopné zakázat svůj tik, když v systému už nic dalšího neběží, ale na současných jádrech není jak takovou situaci odhalit.

Naivní řešení člověka napadne rychle: udržovat globální čítač sledující počet nečinných CPU. Jakmile se procesor stane nečinným, pak se čítač zvýší; jakmile se zase stane aktivním, tak se sníží. Pokud počet nečinných CPU odpovídá počtu CPU v systému, pak jádro ví, že se na ničem nepracuje a i poslední CPU si může oddychnout.

Problém je ale v tom, že přetahování o cache pro tento globální čítač by na větších systémech bylo znát na výkonu. Přechody z a do nečinnosti jsou běžné při většině zátěží, takže linka cache obsahující čítač by byla v systému často přehazována. To by odstranilo jednu z výhod, proč používat dynamický tik; je pravděpodobné, že by většina lidí dala spíše přednost současné neefektivitě co do spotřeby před „řešením“ s tak vysokou režií.

Proto je nutné udělat něco chytřejšího. V tento moment se na scéně objevuje Paul McKenney, jehož sedmidílný patch pro úplnou nečinnost systému může tento problém vyřešit.

Jak se dalo čekat, řešením je udržovat si pole stavů nečinnosti pro každé CPU zvlášť. Každé CPU může aktualizovat svůj stav, aniž by došlo k přetahování s jinými CPU. Naivní řešení je ale i tentokrát neadekvátní. U pole stavů je nutné procházet všemi položkami, aby se zjistil stav všech CPU. Takže nastavování stavu je sice jednoduché, ale hledání odpovědi na otázku „Je systém nečinný?“ je dosti náročné, pokud je CPU mnoho. Vzhledem k tomu, že by tato otázka byla kladena často (alespoň jednou za tik), není možné se spokojit s náročným řešením; je potřeba udělat něco jiného.

Paul to řeší tak, že kombinuje výhody obou naivních řešení. Vytváří jedinou globální proměnnou pro vyjádření nečinnosti systému a tu je jednoduché rychle přečíst. Tato proměnná se aktualizuje po přečtení stavu nečinnosti jednotlivých CPU, ale jen za specifických podmínek, při kterých se minimalizuje přetahování mezi CPU. Výsledek by měl brát to nejlepší z obou řešení za cenu opožděné detekce úplné nečinnosti systému a přidání nějakého toho složitého kódu.

Samotné procházení příznaků nečinnosti pro každé CPU se nedělá v kódu plánovače nebo údržby času, jak by člověk očekával. Místo toho (jak by mohli očekávat jiní) je Paul dal do subsystému RCU. To může vypadat zvláštně, ale dává to smysl: RCU už sleduje stav CPU v systému, kde hledá vhodné chvíle, během kterých je možné uvolnit [reclaim] datové struktury pod ochranou RCU. Sledování, jestli je každé CPU zcela neaktivní, je v kódu RCU relativně malou změnou. Výhodou navrch je to, že je u RCU snadné vyhnout se skenování všech CPU při aktivitě, takže režie údržby globální informace o nečinnosti zmizí, kdykoliv má systém něco na práci.

Samotná nečinnost systému se udržuje v globální proměnné nazvané full_sysidle_state. Časté přepisování této proměnné by znamenalo návrat problému s přetahováním se o linku cache, takže se na to jde oklikou. Kdykoliv se systém považuje za nečinný, tak si kód udržuje informaci, kdy se nečinným stalo poslední CPU. Ke změně globálního stavu dojde jedině po krátké prodlevě. Tato prodleva klesá na nulu u „malých“ strojů (tedy u těch, co nemají více než osm procesorů) a lineárně roste s růstem počtu CPU. Na velmi velkém systému musejí procesory tedy být neaktivní mnohem déle, než se v full_sysidle_state o tom objeví údaj.

Následkem je opoždění detekce úplné nečinnosti systému na větších strojích, možná o velký zlomek sekundy. Proto tik časovače poběží o něco déle, než by musel. To je zkrátka cena, kterou musí člověk při Paulově přístupu zaplatit, stejně jako to, že jeho patch přidává do srdce jádra přibližně 500 řádek kódu kvůli něčemu, co je konec konců jen aktualizace jediné celočíselné hodnoty. Ale to je prostě něco, s čím se člověk musí ve světě, kde systémy mají mnoho CPU, smířit výměnou za škálovatelnost.

       

Komentáře

[Tom K]

Cache line neni linka cache, ale radek v cache.

[Heron]

"Zatímco většina procesorů (za správných okolností) dokáže běžet bez tiku hodin"

Může mi někdo problematiky znalejší objasnit, jak tohle funguje? Měl jsem za to, že když se u procesoru vypne takt, tak už nic vykonávat nemůže, protože jsou všechny jeho pochody hnány právě taktovací frekvencí (synchronně). Nebo ten "tick" je něco jiného a procesor umí vykonávat (asi jen speciální instrukce v nějaké své vnitřní jednotce) i bez toho?

[nosense.cz]

Tento "tik" vůbec nesouvisí s procesorem. Jedná se o pravidelné přerušení (interrupt), které se využívá k přepnutí kontextu do jádra. Jádro se tak může rozhodnout uspat jeden proces a spustit jiný. Zajišťuje se tak multitasking a další jaderné věci.

[Heron]

Už to možná chápu. V článku se sice píše o CPU (hw), ale ve skutečnosti se myslí patrně běh jádra (sw) na daném cpu. Potom by to dávalo smysl. CPU (hw) by běžel na své frekvenci, ale jádro (sw; na něm) by bylo beztikové. A řeší se jak docílit toho, aby i jádro na posledním cpu mohlo být bez tiků. Jasně. Hmm. Jestli je to takto, tak je ten text teda dobrý hlavolam.

[logik]

No mě to teda přišlo jasný...

[Václav HFechs Švirga]

Hehe, díky za rozepsání. Takto to vypadá logicky.

[pc2005]

Jo takhle to chápu taky.

[Václav HFechs Švirga]

Taky by mě to zajímalo.

[trekker.dk]

Nevím, jak u x86, ale u menších procesorů jdou vypnout hodiny s tím, že se automaticky zapnou, když přijde signál od nějaké periférie (tj. přerušení)

[pc2005]

Instrukce HLT. Ale nevím jak dlouho trvá náběh (píšou tam o snížení napětí a vypnutí všěch hodin interně, kromě sběrnice a přerušení), takže minimálně to napětí bude chvíli trvat. Ty tiky kernelu se ale počítaj v řádu milisekund (nedynamický tik je třeba 1000HZ).

Tohle by možná mohlo být, když se třeba čeká na FIFO z UARTu.

[Mintaka]

Nebylo by dobré, mít pro takové případy přímo v procesorech něco jako modul programovatelných hradel? OS by si v této oblasti mohl podle potřeby sestavit specializovaný obvod, který by takové core věci elegantně obhospodařil.

[pc2005]

Hmm automat, co bude udržovat ten čítač nečinných procesorů a rovnou bude moct poskytnout odpověď (třeba při 1000+ jader)? To by šlo, ale hradlové pole v procesoru se mě jeví na tohle jako dost velký overkill (btw tady by to asi nebylo potřeba, ale sekvenční logika v hradlových polí nedává ani zdaleka 1GHz).

Možná by stálo za to integrovat nějaký velmi hloupý procesor, který by dělal takovýho školníka (třeba Cortex-M by ani neměl tak velkou spotřebu). Výhoda by byla ta, že by nezabíral tolik místa, byl rychlejší a pořád by byl docela dobře univerzální.

[Mintaka]

Když by tam byla přijatelná režie na komunikaci mezi hlavním procesorem a jeho "školníkem", proč ne.

[pc2005]

To může být klidně se sdílenou main RAM (nebo okně do ní).

[ebik]

No pak si ale nedovedu představit v čem by byla výkonostní výhoda oproti zde popsanému řešení, které je složité právě proto aby se sdílená ram používala co nejméně.

[pc2005]

Tam byl problém v tom, že všechny procesory mohou tu sdílenou paměť číst i zapisovat. Servisní procesor by jen četl lokální čítače a tvořil by readonly (pro normální procesory) report. Jinak jsem ho navrhl proto, že by mohl ve zbývajícím čase dělat další věci (třeba inteligentně budit spící procesory, viděl jsem i mechanismus spekulativního provádění instrukcí pomocí hloupého jádra).

[ebik]

Hmm, pokud by mohl posílat normálním procesorům interupty, aby ty normální nemusely ten "read-only report" pollovat, pak si dovedu představit, že by to mohlo chodit rychle.

[PetrHL]

Pro články jako jsou Jaderné noviny mi v hodnocení, kromě Špatné a Dobré, chybí ještě položka Skvělé. Díky!