Jaderné noviny - 4. 7. 2007

26. 7. 2007 | Robert Krátký

Články - Jaderné noviny - 4. 7. 2007  

Aktuální verze jádra: 2.6.22-rc7. Citát týdne: Alan Cox. CFS a skupinové plánování. Pokračující příběh fallocate(). Zanášení chyb do jádra. Přepis bufferové vrstvy. Projekt Suspend2 přejmenován na TuxOnIce.

Obsah

• Aktuální verze jádra: 2.6.22-rc7
• Citát týdne: Alan Cox
• CFS a skupinové plánování
• Pokračující příběh fallocate()
• Zanášení chyb do jádra
• Přepis bufferové vrstvy
• Projekt Suspend2 přejmenován na TuxOnIce

Aktuální verze jádra: 2.6.22-rc7

Aktuální předverze je (ke 4. 7. 2007) 2.6.22-rc7, vydaná 1. července: Máme tu snad (téměř určitě) poslední -rc před vydáním 2.6.22 a jsme na tom docela dobře. Přísun patchů se velmi zpomalil a seznam regresí je o mnoho kratší. Poslední šance otestovat 2.6.22 a objevit chyby dřív, než proklouznou do finální verze.

Od vydání -rc7 bylo do hlavního git repozitáře začleněno asi 60 patchů. Šlo především o opravy, ale byla také odstraněna velká skupina soukromých ioctl() funkcí z bezdrátového ovladače libertas (OLPC).

Aktuální verze -mm stromu je 2.6.22-rc6-mm1. Zájemci o kompilaci a testování by si rozhodně měli přečíst Andrewovy poznámky v oznámení. Mezi nedávné změny patří podpora kgdb pro několik architektur, podpora beztikového provozu pro architekturu x86_64, možnost vynutit zapnutí HPET časovače, i když ho BIOS nechá vypnutý, aktualizovaný patch se souborovými POSIX kvalifikacemi a podpora Intel IOMMU.

Citát týdne: Alan Cox

SELinux si objedná objekt fernet.
AppArmor si objedná /fernet.
Barmanka na to: "Oběma je vám míň než 21, nemůžete pít."
SELinux si objedná objekt bavorák.
AppArmor si objedná /bavorák.

SELinux nic nedostane, protože barmanka při míchání bavoráka otevřela objekt fernet a bavorák tak zdědil i typ fernet.
AppArmor se opije, protože /bavorák a /fernet jsou jasně jiné.

-- Alan Cox

CFS a skupinové plánování

Completely fair scheduler (CFS) od Ingo Molnara pokračuje ve vývoji; v tuto chvíli je aktuální verze v18. Jedna z vlastností CFS je však mnoha potenciálními uživateli považována za vážný nedostatek: implementuje férovost pouze mezi jednotlivými procesy. Pokud se v jednu chvíli snaží běžet 50 procesů, CFS zařídí, že každý z nich dostane přesně 2 % procesoru. Mohlo by se však stát, že jeden z těch procesů je Alenin X server, zatímco těch 49 je součástí rozsáhlé kompilace jádra, kterou spustil Karel, ten vychytralý programátor jádra připojený přes net, když se snažil využít trochu volného procesorového času. Pokud už to bereme tak, že je fér, aby byl Karel na systému, tak se zdá také rozumné, že by skupina jeho 49 procesů měla sdílet procesor s Aleniným X serverem. Jinými slovy, X by měly dostat 50 % procesoru (pokud je to potřeba) a všechny Karlovy procesy těch zbývajících 50 %.

Tomuto druhu plánování se říká "skupinové" [group scheduling]; Linux ho s žádným z plánovačů nikdy pořádně nepodporoval. Bylo by fajn, kdyby "zcela férový plánovač", pokud by byl v budoucnu začleněn, měl možnost být zcela férový i v tomto ohledu. Díky práci Srivatsa Vaddagiriho a dalších by se to mohlo podařit.

První část Srivatsovy práce byla začleněna do patche v17 CFS. Vytváří koncept "plánovací entity" - něco, co má být naplánováno, ale nemusí to být proces. Kód bere plánovací informace procesů a balí je do struktury sched_entity. V této podobě je to vlastně jen pročištění kódu - shrnuje relevantní informace (což je samo o sobě užitečné), aniž by se měnila funkce CFS.

Skupinové plánování je implementováno v samostatné sadě patchů, která ještě není součástí kódu CFS. Tyto patche mění plánovací entitu na hierarchickou strukturu. Je tak možné mít plánovací entity, které nejsou přímo spojeny s procesy; místo toho reprezentují určitou skupinu procesů. Každá plánovací entita tohoto typu má v sobě svou vlastní spouštěcí frontu [run queue]. Všechny plánovací entity mají také ukazatel parent a ukazatel na spouštěcí frontu, do které mají být naplánovány.

Ve výchozím stavu jsou procesy na vrchu hierarchie a každý je plánován nezávisle. Ale takový proces může být přesunut pod jinou plánovací entitu, což jej v podstatě odstraňuje z primární spouštěcí fronty. Jakmile je možné proces spustit, je vložen do spouštěcí fronty přiřazené k nadřazené plánovací entitě.

Když si plánovač vybírá, kterou úlohu spustit, podívá se na všechny plánovací entity na vrchní úrovni a vezme tu, o které se domnívá, že si procesor nejvíce zaslouží. Pokud ta entita není proces (jde o plánovací entitu vyšší úrovně), podívá se plánovač na spouštěcí frontu v rámci dané entity a začne znovu. Takhle to pokračuje dolu hierarchií, dokud není nalezen proces - a ten je v tu chvíli spuštěn. Za běhu procesu jsou jako obvykle zaznamenávány jeho runtime [běhové] charakteristiky, ale zároveň jsou tyto informace šířeny hierarchií zpátky nahoru, takže se užití procesoru řádně odrazí na všech úrovních.

Takže teď může administrátor systému vytvořit jednu plánovací entitu pro Alenu a druhou pro Karla. Všechny Aleniny procesy budou umístěny v rámci její plánovací entity; podobné to bude se všemi procesy Karlovy kompilace jádra. CFS plánovač zaručí férové rozdělení;jakmile se rozhodne, komu zrovna náleží procesor, sejde o úroveň níže a provede férové plánování na procesech dotyčného uživatele.

Vytváření procesové hierarchie však nemusí být modelované podle uživatelů; mohou být organizovány, jakkoliv se administrátorovi zlíbí. Seskupování může mít širší pravidla - například na univerzitním stroji by mohli být všichni studenti zařazeni do jedné skupiny a učitelé do druhé. Nebo to může být založeno na druhu procesu: můžeme mít třeba plánovací entity pro systémové démony, interaktivní nástroje, super žravé drtiče procesoru atd. Patch nikterak neomezuje způsoby seskupování procesů.

Zůstává jedna otázka: jak vlastně administrátor tohle seskupování zařídí? Odpověď je ve druhé části patche se skupinovým plánováním, která integruje plánovací entity do mechanismu kontejnerů procesů. Administrátor připojí kontejnerový souborový systém s parametrem cpuctl; v tomto souborovém systému pak mohou být vytvářeny plánovací skupiny jako adresáře. Procesy lze do (a ze) skupin přesouvat pomocí běžného kontejnerového rozhraní. Takže jakoukoliv sadu pravidel je možné implementovat prostřednictvím jednoduchého uživatelského démona, který bude reagovat na vytváření procesů umístěním nově vytvořených procesů do správné skupiny.

V současné podobě podporuje kontejnerový kód jen jedinou úroveň hierarchie skupin, takže není možné implementovat dvojúrovňové schéma (rozděl uživatele na administrátory, zaměstnance a hosty a pak vynuť férovost mezi uživateli v každé skupině). Zdá se však, že je jen otázkou času, než bude toto omezení odstraněno.

Po přidání této funkce začne být CFS pro mnohé potenciální uživatele o dost zajímavější. Budou si však muset ještě chvilku počkat. Období pro začleňování do 2.6.23 začne brzy, ale nevypadá to, že by v tu chvíli již byla práce připravena jít do jádra. 2.6.24 by mohla být ta správná verze pro lidi, kteří chtějí zbrusu nový plánovač, který myslí i na skupiny.

Pokračující příběh fallocate()

V březnu jsme mluvili o navrhovaném systémovém volání fallocate(), které má za účel aplikacím umožnit prealokovat bloky pro soubor. Od té doby se o věci docela dost diskutovalo, ale fallocate() zatím v hlavním jádře není - a není ani jasné, jestli bude v 2.6.23. V oběhu je však nová verze fallocate() patche, takže se zdá, že je načase se podívat, co nového.

V březnu vypadalo navrhované rozhraní takto:

    long fallocate(int fd, int mode, loff_t offset, loff_t len);

Ale ukázalo se, že na některých arcitekturách by bylo obtížné takovou sadu parametrů podporovat - především jde o architekturu S/390. Bylo navrženo několik alternativ, ale zdá se dost obtížné najít něco, co by se líbilo všem. Nakonec se stále používá výše uvedený prototyp, ačkoli kód pro architekturu S/390 s tím bude muset ještě trochu zamíchat - ale asi je to nejschůdnější cesta.

To však neznamená, že by byl debatám o rozhraní konec. Aktuální verze patche má čtyři možnosti pro mode:

• FA_ALLOCATE alokuje požadovaný prostor na daném offset. Pokud takové volání soubor zvětší, zvětší se podle toho i hlášená velikost souboru, takže se alokované bloky stanou okamžitě součástí souboru.


• FA_RESV_SPACE prealokuje bloky, ale nezmění velikost souboru. Takže pokud budou nově alokované bloky za koncem souboru, nebude to vypadat, že tam jsou, dokud do nich aplikace nezapíše (nebo jinak nezvětší velikost souboru).


• FA_DEALLOCATE vrátí do systému dříve alokované bloky. Velikost souboru se změní, pokud jsou dealokované bloky na jeho konci.


• FA_UNRESV_SPACE vrátí bloky do systému, ale nezmění velikost souboru.

Jako příklad rozdílnosti posledních dvou operací si představte, co se stane, když aplikace použije fallocate() pro odstranění posledního bloku ze souboru. Pokud byl odstraněn pomocí FA_DEALLOCATE, nevrátí následný pokus o přečtení bloku žádná data - offset, kde byl blok, je teď za koncem souboru. Pokud je však blok odstraněn pomocí FA_UNRESV_SPACE, vrátí pokus o přečtení blok plný nul.

Vypadá to však, že existují rozdílné názory na to, jak by mělo rozhraní fungovat. Byla požadována triviální změna, která spočívala v náhradě prefixu FA_ na FALLOC_ - této žádosti bude pravděpodobně vyhověno. Lidé by však rádi zařadili ještě několik dalších příznaků:

• FALLOC_ZERO_SPACE by do požadovaného rozsahu zapsal nuly - i kdyby už byl rozsah alokován pro soubor. Taková funkce by byla užitečná, protože některé souborové systémy mohou příslušný rozsah rychle označit jako neinicializovaný, místo aby do všech těch bloků zapsaly nuly.


• FALLOC_MKSWAP by alokoval prostor, označil ho jako inicializovaný, ale nuly by do bloků nezapsal. Nově alokvané bloky by tím pádem stále obsahovaly data, která tam zanechal předchozí uživatel. Tato operace, pro kterou by zjevně bylo zapotřebí větších práv, je určena pro velmi rychlé vytváření swap souborů. Nevyžadovalo by to moc práce v oblasti jaderné alokace paměti, takže by se to hodilo jako užitečný způsob pro přidání swap souboru v kritických okamžicích, kdy systému dojde paměť.
  
  
• FALLOC_FL_ERR_FREE by byl dodatečný příznak pro zpracovávání chyb; konkrétně by se staral o chování ve chvíli, kdy souborovému systému dojde místo během alokačního procesu. Pokud by byl příznak nastaven, byly by úspěšně prealokované bloky uvolněny - jinak by byly ponechány na místě. Ne všichni však s tímto příznakem souhlasí; možná bude vynechán a místo něj se pro prealokace zavede oficiální pravidlo "všechno nebo nic".


• FALLOC_FL_NO_MTIME a FALLOC_FL_NO_CTIME by souborovému systému zabránily aktualizovat čas modifikace souboru.

Je to slušná řádka nových funkcí - dost na to, aby někteří vývojáři začali uvažovat o tom, jestli je fallocate() ten správný přístup. Především Christoph Hellwig si začal stěžovat; navrhuje přidání něčeho malého, co by umělo implementovat posix_fallocate() a nic víc. Mazání bloků je podle něj jiná funkce a mělo by se o ni starat jiné systémové volání. Ostatní funkce by potřebovaly lépe promyslet (a bez milosti probrat). Není tedy jasné, co tento patch čeká, a jestli se o něm bude uvažovat pro 2.6.23.

---

Následující obsah je © KernelTrap

Zanášení chyb do jádra

20. čer, originál

Během diskuze o sledování regresí jádra Linus Torvalds poznamenal, že vzhledem k rychlosti vývoje jádra je zanášení chyb nevyhnutelné. Použil git k tomu, aby zjistil, že každý den je začleněno více než 65 patchů: To znamená 500 commitů za týden, dva _tisíce_ commitů měsíčně a 25 tisíc commitů ročně. Docela rovnoměrný proud. Najdou se v tom i chyby? No jasně! A doplnil: A tvrdím, že jakýkoliv postup, který se snaží 'zaručit' bezchybný průběh, je vadný. Je to ideální způsob jak otrávit lidi, protože to prostě od vývojářů a správců vyžaduje úroveň dokonalosti, která není možná. Připojil pak ještě pár výpočtů o kódu přidaném za posledních sto dní:

I při nejpřísnějších opatřeních přidáme každé čtyři dny chybu. To je prostě fakt, který je nutné akceptovat. Když někdo říká, že nesmíme připustit regrese, nežije na planetě Zemi, ale v pohádkovém světě, kde neexistují chyby, vývojáři jsou tam dokonalí, hardware je také dokonalý a správci všechny problémy zachytí.

Přepis bufferové vrstvy

24. čer, originál

V komentáři k sérii tří patchů Nick Piggin uvedl, že pracuje na přepisu bufferové vrstvy: Říkám tomu fsblock, protože to vlastně váže vrstvu souborových systémů k blokové vrstvě. Bufferovou vrstvu Nick vysvětlil takto: Jde o vrstvu mezi keší stránek a blokovým zařízením pro souborové systémy založené na blocích. Uchovává překlad mezi logickým offsetem a číslem fyzického bloku a také meta informace jako zámky, čistotu a IO stav každého bloku. Informace jsou sledovány pomocí struktury buffer_head. Ještě než vyjmenoval vylepšení, která přináší přepis vrstvy, nabídl také důvod celého snažení:

Proč přepisovat bufferovou vrstvu? Dost lidí si přálo tu vrstvu úplně vyhodit, ale to nemůžeme, protože má ve skutečnosti užitečné poslání. Tak proč má tak špatnou pověst? Kód je starý a kostrbatý a buffer_head je děsný název. Patří pravděpodobně k nejstarším kusům kódu ve FS/VM - důvodem je nevole ke změně tolika komplikovaných souborových systémů.

Projekt Suspend2 přejmenován na TuxOnIce

3. črc, originál

Nigel Cunningham v LKML oznámil, že projekt 'Suspend2' byl přejmenován na 'TuxOnIce': Má to několik důvodů: v diskuzích bylo poukazováno na to, že slovo 'Suspend' je matoucí. Používá se k označování uspávání na disk i do RAM, a proto bude jednodušší, když to trochu rozlišíme. Název Suspend2 se objevil, když jsme před pár lety vydali verzi 2.0 a přesunuli web na vlastní doménu. Pokud bychom se někdy dostali k 3.0, bylo by to ještě zmatenější (už teď si to jméno lidé pletou se swsusp o a uswsusp mluví jako o verzi 3).

Objevily se obavy, že by tento krok mohl naznačovat konec snahy o začlenění přepsané uspávací infrastruktury do hlavního jádra. Nigel vysvětlil: Pokud vím, tak já i Rafael i nadále plánujeme pokusit se o začlenění alespoň části tohoto kódu. Zatím se tak neděje pouze proto, že máme oba dost práce s jinými věcmi, které je potřeba dokončit. Rafael se zaměřil na otázky infrastruktury a já na minimalizaci diffu a dokončení pročišťování kódu a přidávání komentářů k funkcím. Rafael Wysocki souhlasil: Mým prvním cílem je doplnění systému, který by ovladačům umožňoval používat jiná zpětná volání pro hibernaci a uspávání. Bohužel se ukázalo, že s tím bude hodně práce, která zabere dost času.

Diskuse k tomuto článku

[Milan Lajtoš]

Cast o CFS je naozaj zaujimava na citanie.. Dizajn kernelu nie je moj obor, takze sa naucim aspon nieco nove.. ;)

[PEter]

+1

[disorder]

3. črc, originál

tuxonice mi aj tak nefunguje. neva, uswsusp funguje skvele, aj samotny zapis do /sys funguje dobre.

[Jooky (inactive)]

Ja pouzivam suspend2 dost dlho. Je pravda ze som dlhsiu dobu stravil nez som nastavil hiberante.conf, ale funguje ako ma :o)

[disorder]

mi neponuka nic naviac oproti uswsusp, ktory navyse funguje bezchybne "out of the box"

[miso]

Ako poznamenal kolega: 21 sa preklada ako 18

[Michal]

To neni chyba prekladu ale nasi legislativy...

[kralyk z abclinuxu]

No to snad ne...
I kdzy, je to vlastne jedno, na legislative nezalezi, jak si vzpominam kupoval sem alkohol uz v 15, mozna i driv...

[Murry]

Velmi zajimave. Uz se tesim na dalsi .......

[Creator of Myths]

Zpozdeni uz cini jen tri tydny, slava Jeste stahnete jeden tyden, prosim, a bude to dokonale. Diky za preklad.

[Peto_MiG]

+1

[trekker.dk]

podpora beztikového provozu pro architekturu x86_64

Nevíte někdo, jak to zapnout? V menuconfigu není žádná volba a v defaultním .config jsem nenašel ani CONFIG_NO_HZ is not set

[disorder]

http://www.tglx.de/projects/hrtimers/

[trekker.dk]

Beztikový provoz by snad měl být přímo v jádře, ne? Aspoň pro x86_32 tam byl.

[disorder]

ore x86_64 a ine 64-bit architektury este nie

[trekker.dk]

Už to vidím, ono je to v -mm.

[disorder]

v 2.6.23, predpokladam. to bude tym, ze sa to tam ma dostat, predtym to tam nebolo.

[David Watzke]

To znamená 500 commitů za týden, dva _tisíce_ commitů měsíčně s 25 tisíc commitů ročně.

s/ s / a /

No, docela to tam žije