29.7.2013 14:04
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Rozbalit Rozbalit vše Re: Jaderné noviny – 11. 7. 2013: Další redukce tiku v jádře
Portál AbcLinuxu, 25. května 2025 19:36
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ý?.
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.
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.
Š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.
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ří:
Mezi změny viditelné jaderným vývojářům patří:
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.
29.7.2013 14:04
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
29.7.2013 15:56
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
30.7.2013 13:49
Mintaka | skóre: 13
(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í.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.