Portál AbcLinuxu, 5. května 2025 17:32

Jaderné noviny - 17. 10. 2007

6. 11. 2007 | Robert Krátký
Články - Jaderné noviny - 17. 10. 2007  

Aktuální verze jádra: 2.6.23. Citáty týdne: Linus Torvalds, Alan Cox. Začleněno do 2.6.24. Férové plánování pro uživatele a další plánovací patche. Změny operací s adresním prostorem u VFS.

Obsah

Aktuální verze jádra: 2.6.23

link

Pro hlavní řadu nevyšla žádná předverze; okno pro začleňování nového kódu do 2.6.24 zůstává otevřeno. Do hlavního repozitáře rychle proudí patche; nejzajímavější věci jsou představeny níže v textu.

Aktuální verze -mm stromu je 2.6.23-mm1. Nedávné změny: infrastruktura pro novou funkci správy napájení "kvalita služeb", několik aktualizací ext4 a patch s jadernými značkovači.

Aktuální stabilní jádro řady 2.6 je 2.6.23.1, vydané 12. října. Aktualizace obsahuje jedinou opravu problému s poškozením dat v ovladači sata_mv.

Starší jádra: 2.6.16.55 bylo vydáno 14. října s několika bezpečnostními opravami.

Citáty týdne: Linus Torvalds, Alan Cox

link

Ne každý je "dělač". Je důležité získávat zpětnou vazbu i od lidí, kteří jsou obyčejní uživatelé - nebo by chtěli být.

-- Linus Torvalds

-Limit délky řádků je 80 znaků - nesmí být překročen.
+Limit délky řádků je 80 znaků - pokud možno by neměl být překročen.

-- Alan Cox v 2.6.24 uvolňuje pravidla.

Začleněno do 2.6.24

link

Začleňování nového kódu stále probíhá; doposud si do jádra našlo cestu asi 5600 patchů. Jako obvykle je seznam změn velmi dlouhý. Mezi ty zajímavější změny, kterých si všimnou i uživatelé, patří:

Důležité změny viditelné pro vývojáře jádra:

Dá se očekávat, že období pro začleňování do 2.6.24 potrvá ještě týden, takže než nastane stabilizační fáze, do hlavního stromu se určitě dostane ještě více změn.

Férové plánování pro uživatele a další plánovací patche

link

Completely Fair Scheduler (CFS) byl začleněn v jádře 2.6.23. Nedostalo se však na skupinové plánování, s jehož pomocí funguje CFS algoritmus hierarchicky: procesy jsou rozděleny do skupin a v rámci každé skupiny jsou procesy navzájem férově plánovány. Na vyšší úrovni je každé skupině přidělen férový podíl procesoru. Seskupování procesů je velmi flexibilně prováděno v uživatelském prostoru; mechanismus kontrolních skupin (dříve "kontejnerů procesů") umožňuje klasifikaci procesů podle skoro jakýchkoliv pravidel.

Jedním z důvodů, proč se skupinové plánování nedostalo do 2.6.23, je skutečnost, že patch přidávající podporu pro kontrolní skupiny nebyl hotový. Vypadalo to, že se dostane do 2.6.24, ale v tuto chvíli se zdá, že je ještě příliš aktivně vyvíjen, aby mohl do hlavního jádra. Skupinové plánování však nečeká; do 2.6.24 už bylo zařazeno. Kvůli nepřítomnosti podpory kontrolních skupin však nebude mechanismus skupinového plánování k dispozici. Za posledních několik měsíců se ale u skupinového plánování vyvinula nová funkce, která umožní použití i bez kontrolních skupin, a která implementuje způsob, jak bude pravděpodobně skupinové plánování nejčastěji používáno.

Jde o plánování pro jednotlivé uživatele: vytvoří se samostatná skupina pro každého uživatele na systému a s pomocí těchto skupin je každému uživateli přidělen férový podíl procesoru. Protože jsou skupiny automaticky vytvářeny plánovačem, není nutné mít pro ovládání skupin samostatné rozhraní. Místo toho se zvolí konfigurační volba "férové uživatelské" a skupinové plánování pro jednotlivé uživatele se zapne bez jakéhokoliv dalšího zásahu.

Je samozřejmé, že jakmile začne systém poskytovat férové plánování pro jednotlivé uživatele, administrátoři budou chtít, aby férové nebylo, a zařídí, aby někteří uživatelé dostali více procesoru než jiní. Léty prověřený způsob zvyšování priority toho nezbytně důležitého administrátorského procesu wesnoth pořád funguje, ale je to hrubé a průhledné řešení. Bylo by mnohem lepší mít možnost vyladit plánovač tak, aby jistí uživatelé dostali vyšší díl procesoru pro provozování svých zásadních her video diagnostických nástrojů.

Aby se podobného účinku dosáhlo s plánovačem v 2.6.24, bude pouze nutné jít do nového adresáře /sys/kernel/uids. Tam bude podadresář pro každé aktivní uživatelské ID na systému a každý podadresář bude obsahovat soubor nazvaný cpu_share. Výchozí celočíselná hodnota v tomto souboru bude 1024. Pro účely úprav plánování je podstatný pouze poměr hodnoty cpu_share vůči dalšímu uživateli. Je-li cpu_share jednoho uživatele nastaveno na 2048, dostane takový uživatel dvakrát více procesoru než kterýkoliv další uživatel, jehož hodnota zůstala 1024. Výsledkem je to, že úprava plánování procesoru mezi uživateli je pro administrátory velmi jednoduchá.

Do 2.6.24 bylo také začleněno docela dost dalších patchů. Většinou jde o pročišťování a menší vylepšení. Některé počty v rámci plánovače byly zjednodušeny a několika způsoby byla zlepšena férovost. Přibyla také možnost provádět správu procesorových zdrojů pro hostované virtualizované systémy běžící pod KVM. Patchů je to hodně, ale tempo změn v jádře plánovače procesoru by se mělo už zase začít zpomalovat.

Pracuje se však ještě na dalších věcech souvisejících s plánovačem. Dvě z nich řeší problém, jak rychle dostat do procesoru realtimové úlohy. Za normálních podmínek se plánovač bude docela dost snažit, aby nemusel přesouvat procesy mezi procesory, protože režie takové migrace (způsobená ztraceným obsahem keše paměti) je vysoká. Pokud však chce běžet realtimový proces, musí mu systém poskytnout procesor i za cenu snížení celkové propustnosti. Aktuální plánovač však nechá realtimový proces čekat, běží-li na stejném procesoru proces s vyšší prioritou, i když jsou v systému k dispozici jiné procesory.

Nápravou tohoto problému se zabývají dva patche. První od Stevena Rostedta řeší situaci, při které plánování jedné realtimové úlohy způsobuje vyšoupnutí úlohy s nižší prioritou (ale i tak realtimové) z procesoru. Než aby ta jedna smolařská úloha zůstávala ve frontě, prohledává Stevenův patch ostatní procesory v systému, aby našel ten, kde běží proces s nejnižší prioritou. Podaří-li se nalézt procesor s procesem s dostatečně nízkou prioritou, bude na něj přesunut vyšoupnutý realtimový proces.

Gregory Haskins poslal podobný patch, který řeší mírně odlišnou situaci: právě byla probuzena realtimová úloha, ale procesor, na kterém je, už provádí proces s vyšší prioritou. Opět následuje hledání procesoru s procesem s nízkou prioritou, přičemž realtimový proces je přesunut, pokud se podaří vhodnější procesor najít. V obou případech přesouvaný proces výkonnostně trochu utrpí, protože na něj čeká úplně čistá keš. Ale i tak bude schopen reagovat mnohem rychleji, než kdyby někde seděl ve frontě; a o to především u realtimového plánování jde.

Další potíž, která se v některých situacích projevuje, je to, že je přesnost plánování omezena tikovou frekvencí plánovače. V případě absence externích událostí (třeba dokončení I/O operací) může jeden proces předejít jiný jen při dalším periodickém tiku. V důsledku toho mohou procesy běžet déle, než by jim jejich přidělený časový úsek jinak dovolil. Plánovač to kompenzuje tak, že nechá daný proces déle čekat na svůj další příděl. Plánování je tedy férové, ale s vyššími latencemi.

Peter Zijlstra poslal řešení tohoto problému: patch, který používá mechanismus časovačů s vysokým rozlišením, aby dosáhl preempce procesů přesně s vypršením jejich časových přídělů. Když si plánovač všimne, že časový úsek vyprší v době mezi tiky časovače, zařídí speciální jednorázové časovačové přerušení pro okamžik vypršení časového přídělu. Když pak přijde přerušení, může být běžící proces vykopnut přesně na čas. Díky tomu nepřetáhne proces svůj příděl a nebude muset před dalším přídělem čekat déle než obvykle.

Mike Galbraith hlásil, že tento patch má na jeho systému za následek méně přepínání kontextů a také vyšší propustnost. Vypadá to tedy jako správné řešení problému - když není k dispozici mechanismus pro opravdu dynamický tik. Stávající kód implementující dynamický tik vypíná při nečinnosti procesoru periodické časové přerušení, ale při zaměstnaném procesoru přerušení dále běží. V plně dynamickém prostředí by periodické tiky vůbec nebyly používány a speciální přerušení na konci časových přídělů by byly běžný způsob práce. Implementace plně dynamického tiku je však velký úkol; mezitím může plánovači s přesností pomoci občasný extra tik.

Změny operací s adresním prostorem u VFS

link

Hluboko utopena v závalu patchů pro 2.6.24 je sada významných změn v interním API VFS vrstvy. Hlavní motivací této práce je snaha zabránit problému se zatuháváním, kterému se starým API nešlo předejít bez výrazného poklesu výkonnosti. Všichni, kteří spravují souborové systémy mimo hlavní jádro, by se na změny měli podívat a připravit se na opravu svého kódu.

Ve starším VFS API poskytovaly souborové systémy pro podporu zápisů do souborů dvě operace s adresními prostory:

    int (*prepare_write)(struct file *file, struct page *page, 
    			 unsigned begin, unsigned end);
    int (*commit_write)(struct file *file, struct page *page, 
    			 unsigned begin, unsigned end);

Volání prepare_write() uvědomí souborový systém, že se VFS chystá zapisovat bajty begin..end z file do dané page. Pak už musí souborový systém zařídit, aby zápis fungoval (včetně alokace bloků, je-li to třeba). Má-li být zapsána jen část bloku, měl by souborový systém vyplnit page se všemi daty bloku. Později volání commit_write() řekne souborovému systému, že byla data zkopírována do page, a mohou být uložena na disk.

Potíž s tímto API je v tom, že od VFS se očekává předání zamčené stránky do prepare_write(). Existuje několik postupů, které mohou vést ke snaze uzamknout tu stránku dvakrát, což by systém zastavilo. Aby se problému předešlo, vytvořil Nick Piggin náhrady za prepare_write() a commit_write():

    int (*write_begin)(struct file *file, struct address_space *mapping,
		       loff_t pos, unsigned len, unsigned flags,
		       struct page **pagep, void **fsdata);
    int (*write_end)(struct file *file, struct address_space *mapping,
		     loff_t pos, unsigned len, unsigned copied,
		     struct page *page, void *fsdata);

Je tam dost změn, ale klíčová je skutečnost, že stránka už není předávána do write_begin(). Místo toho by měla funkce alokovat stránku sama a vrátit ji (zamknutou) VFS. Volání write_end() značí, že je zápis kompletní; mělo by stránku odemknout a aktualizovat pole i_size inody.

Důležitý je také nový parametr copied: je to počet bajtů, které byly na stránku opravdu nakopírovány - může být menší než předpokládaná len. Některé z možných případů zamrznutí se vyskytly při zpracovávání výpadků stránek, zatímco byla cílová stránka uzamčena; triviálním příkladem je zápis dat na stránku, zatímco jsou stejná data zároveň z dané stránky čtena. S novým API se výpadek stránky při kopírování dat přeruší, což umožní odemknutí stránky. Výpadek může být zpracován, když je stránka odemknuta, a tím se zabrání zatuhnutí.

Možnost krátkých zápisů klade na souborové systémy extra nároky: data, která je možné přepsat, musí být stejně načtena - pro případ, že by operace zápisu skončila předčasně. Existují však situace, kdy VFS ví, že zápis doběhne až do konce; především zápisy z bufferů v jaderném prostoru musejí uspět. Když je takový zápis spuštěn, VFS předá příznak AOP_FLAG_UNINTERRUPTIBLE do write_begin(), aby dal souborovému systému vědět, že krátké zápisy nejsou možné.

Prozatím jsou VFS metody prepare_write() a commit_write() v jádře stále podporovány. Pokud souborový systém neposkytuje nové funkce, použijí se staré. Do budoucna je však určitě v plánu tyto metody odstranit; nelze je podporovat tak, aby byly zároveň bezpečné a rychlé.

Související články

Jaderné noviny - 10. 10. 2007
Jaderné noviny - 3. 10. 2007
Jaderné noviny - 19. 9. 2007
Jaderné noviny - 12. 9. 2007

Odkazy a zdroje

Kernel coverage at LWN.net: October 17, 2007

Další články z této rubriky

Jaderné noviny – přehled za březen 2025
Jaderné noviny – přehled za únor 2025
Jaderné noviny – přehled za leden 2025
Jaderné noviny – přehled za prosinec 2024
Jaderné noviny – přehled za listopad 2024

Diskuse k tomuto článku

6.11.2007 00:07 trekker.dk | skóre: 72
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Odpovědět | Sbalit | Link | Blokovat | Admin
Překlep?
Skupinové plánování však nečeká; do 2.6.224...
Quando omni flunkus moritati
6.11.2007 02:17 Jiří J. | skóre: 34 | blog: Poutník | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Odpovědět | Sbalit | Link | Blokovat | Admin
jen jsem to proletěl ..
Alokace čísel UDP portů je teď náhodná.
Prcek avatar 6.11.2007 03:54 Prcek | skóre: 43 | Jindřichův Hradec / Brno
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
označen jako zastaralý a v nové kódu by neměl být používán
Plínování je tedy férové, ale s vyššími latencemi.
Člověk je takový, jak vypadá... A já vypadám jako pravá, nefalšovaná děvka!!!
Pavel Vymetálek avatar 6.11.2007 06:46 Pavel Vymetálek | skóre: 15 | Náchod
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Odpovědět | Sbalit | Link | Blokovat | Admin
Výborné počteníčko, kapitola o plánovači se dá číst skoro jako detektivka. Jaderné noviny jsou prostě báječné. Díky za to.
6.11.2007 09:20 Andy | skóre: 18 | NMnMet
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Odpovědět | Sbalit | Link | Blokovat | Admin
Je moc zajimavy, ze 2.6.23 ma jedinou opravu (2.6.23.1) a uz to trva skoro mesic. Az se mi to nechce verit.

Jinak JN taky moc rad ctu. Diky.
Válka je vůl ... a já taky ;) | Chaotic state of my influence.
Petr Tomášek avatar 6.11.2007 09:21 Petr Tomášek | skóre: 39 | blog: Vejšplechty
Rozbalit Rozbalit vše „do 2.6.224 už bylo zařazeno“
Odpovědět | Sbalit | Link | Blokovat | Admin
a sakra, to mam nejaky zastaraly jadro :-D
multicult.fm | monokultura je zlo | welcome refugees!
6.11.2007 10:34 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Odpovědět | Sbalit | Link | Blokovat | Admin
Díky všem za opravy.
6.11.2007 10:59 helemesecotonese
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Odpovědět | Sbalit | Link | Blokovat | Admin
"dělač" -> "pracant"?
6.11.2007 11:10 helemesecotonese
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
doer - muž činu
doer - dříč
doer - člověk, který jedná
predtim jsem varil z vody, ani jsem se nekoukl do puvodniho zneni, ale daleko od pravdy jsem nebyl...
6.11.2007 11:27 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Vím, ale "dělač" je přeci príma slovo. Pravda, i spellcheck mě za něj seřval, ale nenechal jsem se odradit.
6.11.2007 12:59 XxX
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Verim ze s 2.6.24 prijde enormni pocet bugu, proto jsem neupdatoval ani na 2.6.23 a stale uzivam 2.6.22.10. Pokud se neco nezmeni, zustavam u 2.6.22.10 jeste nekolik mesicu, budu si jen backportovat security fixy a bug fixy, cim novejsi kernel, tim horsi. Nejlepsi je nyni rada 2.4, skoda ze muj HW neni dostatecne zastaraly, aby s 2.4 fungoval. Ten traffic shaping je katastrofa od doby, kdy v 2.6.10 byl vyrazen conntrack_rate z iptables. Chcete DROPovat cast prichoziho trafficu, ktera se prijma vyssi rychlosti, nez jste si urcili a musite si studovat qdisk, tc, zjistovat jak upravit tun/tap, aby fungoval bridge a procitat tisice radku dokumentace jen kvuli takove primitivni zalezitosti... Delac je pitomost....
6.11.2007 13:17 xm | skóre: 36 | blog: Osvobozený blog | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
LOL :-D
Svoboda je tím nejdůležitějším, co máme. Nenechte se o ní připravit, podporujte Pirátskou stranu!
6.11.2007 19:53 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Obavam se ze jsi mimo...
www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
6.11.2007 20:02 Michal Kubeček | skóre: 72 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Verim ze s 2.6.24 prijde enormni pocet bugu, proto jsem neupdatoval ani na 2.6.23

To se bojíte, že by část toho hmyzu mohla přelézt na sousední verzi? :-)

freshmouse avatar 6.11.2007 20:24 freshmouse | skóre: 42 | blog: Bruno Banány
Rozbalit Rozbalit vše Re: Jaderné noviny - 17. 10. 2007
Mně se náhodou dělač líbí; v tom kontextu, ve kterém to je, to je dokonce úplně super překlad. :-)

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.