Portál AbcLinuxu, 4. května 2025 23:21
Aktuální verze jádra: 2.6.21-rc3. Citáty týdne: Con Kolivas, Andrew Morton, Linus Torvalds. Rotating Staircase Deadline Scheduler. Správa paměti. Představení utrace.
Aktuální předverze řady 2.6 je (k 7. 3. 2007) 2.6.21-rc3, vydaná 6. března. Obsahuje dost oprav a několik vylepšení KVM. Linus k ní řekl: ...doufáme, že bude fungovat více lidem než -rc1 a -rc2. Podrobnosti najdete v dlouhém changelogu.
Od vydání -rc3 nebyly do hlavního git repozitáře začleněny žádné patche.
Aktuální verze -mm stromu je 2.6.21-rc2-mm2. Mezi nedávné změny patří sada patchů proti fragmentaci paměti (vizte níže), odstranění patchů s bufferovaným I/O k souborovým systémům, bezdrátový stack Deviscape (přejmenovaný na "mac80211") a nová funkce pro alokaci paměti krealloc().
Starší jádra: 2.6.19.6 a 2.6.19.7 vyšla 2. března. Obsahují slušnou řádku oprav, z nichž přinejmenším jedna se týká bezpečnosti: Nepřihodí-li se něco závažného, tak už další verze 2.6.19 nevyjdou. Pokud s tím nesouhlasíte, dejte prosím týmu -stable vědět, které patche byste do dalšího vydání chtěli. Potřebovali bychom se dostat k vydání dlouhé řady patchů pro 2.6.20-stable.
2.6.16.43-rc1 vyšlo 1. března. Obsahuje dost oprav a několik nových ovladačů hwmon
Jo, tak ty máš vm patch, který pomáhá se swapováním na desktopu! S tím ti mohu pomoci, mám vlastní zkušenost se swap prefetch [přednačítání swapu].
1. Nech to zkontrolovat co nejvíce lidem a dej si pozor, aby nikdo neukázal důkaz, že to něčemu škodí.
2. Najdi stovky uživatelů, kteří potvrdí, že to pomáhá.
3. Vymysli způsob, jak to vyčíslit...
4. ...
5. Zařaď do hlavního jádra.
Tak, to by ti mělo pomoci až k bodu 4. Ještě jsem ale nezjistil, co ten bod 4 je. Říkám si, že to asi bude "goto 1;" [zpět na 1].
-- Con Kolivas (díky Josu Poortvlietovi).
-mm je v současné době hnus. Totiž, hlavní jádro je teď hnus a -mm je hnus^2. Asi je načase hodit velké množství kódu přes palubu.
Už mám fakt plné zuby stahování [pull] velkých změn po ukončení období pro začleňování [merge window] - vypadá to, že to ani trochu nepolevuje. Na dalšího vývojáře, který nerozumí tomu, co znamená "období pro začleněňování" a "pouze opravy", vyjedu jako postal.
[Poznámka: "to go postal" znamená začít řádit nebo se chovat násilně a vztekle. Výraz vznikl v reakci na sérii násilných činů, jejichž hlavními aktéry byli pracovníci pošt ve Spojených státech. Ve většině případů začali bez předchozího varování střílet na své spolupracovníky, nadřízené nebo zákazníky a pak se (v některých případech úspěšně) pokusili zabít i sebe.]
Plánování práce procesoru [CPU scheduling] se zdá být jedním z úkolů, které nebudou nikdy hotové. Vývojáři mohou na plánovači nějakou dobu pracovat a zařídit, aby fungoval lépe, ale vždycky se najdou zátěže, které nejsou tak dobře zvládnuty, jak by se uživatelům líbilo. Především uživatelé interaktivních systémů jsou citliví na latence plánovačů. Kvůli tomu má stávající plánovač propracovanou sadu heuristik, jež se snaží rozpoznat, které procesy jsou doopravdy interaktivní, a dát jim prioritu. Výsledkem je komplikovaný kód - a lidi si i tak stále stěžují na dobu interaktivní reakce.
Con Kolivas už na zlepšování interaktivity nějakou dobu pracuje. Jeho zatím poslední návrh ja Rotating Staircase Deadline Scheduler (RSDL, rotační schodišťový plánovač s příděly), který se pokouší o poskytnutí dobré interaktivní reakce při zachování relativně jednoduchého designu, úplné nestrannosti a omezené latence. Nápady přebírá z Conova dřívějšího schodišťového plánovače [staircase scheduler] (vizte článek z června 2004), ale přístup je velmi odlišný.
Jako mnohé jiné plánovače, i RSDL si udržuje pole priorit, jehož hrubý nákres můžete vidět nalevo. Na každé úrovni je seznam procesů, které by v tu chvíli chtěly běžet s danou prioritou; každý proces má vymezený čas, po který může být s takovou prioritou vykonáván. Procesy na úrovni nejvyšší priority dostávají časové úseky a plánovač je rotuje podle klasického algoritmu cyklické obsluhy [round-robin].
Jakmile proces vypotřebuje svůj přidělený čas na dané úrovni priority, je shozen na nižší prioritu a dostane nový příděl času. Takže tento proces může běžet dál, ale až tehdy, kdy se vystřídají procesy s vyšší prioritou. Jak se procesy posunují po schodišti dolů, musí čím dál více soupeřit s procesy s nižší prioritou, které dosud trpělivě čekaly na nižších úrovních. Vyplývá z toho, že i procesy s nejnižší prioritou nakonec nějaký ten procesorový čas dostanou.
Zajímavou vlastností tohoto plánovače je skutečnost, že i každá úroveň priority má svůj vlastní příděl. Jakmile úroveň s nejvyšší prioritou vyčerpá svůj příděl, všechny běžící procesy z dané úrovně jsou přesunuty do další (nižší) úrovně - bez ohledu na to, jestli už vypotřebovaly svůj příděl procesorového času nebo ne. Díky tomuto mechanismu "malé rotace" se procesy čekající na úrovních s nižší prioritou musí nudit jen omezenou dobu, než dojde k tomu, že všechny ostatní procesy poběží na jejich úrovni. Maximální latence kteréhokoliv procesu je tedy omezena a lze ji vypočítat; s tímto plánovačem nikdy nedochází k úplnému odstavení od procesoru [starvation].
Jak procesy vypotřebovávají svůj čas, jsou přesouvány do druhého pole, které se nazývá "expired" [vypršelé]; tam jsou umístěny zpátky na svou původní prioritu. Tyto procesy neběží; jsou udržovány v chládku, dokud ještě nějaké procesy zbývají v aktuálně aktivním poli - nebo dokud nejsou všechny procesy v aktivním poli vytlačeny na nejnižší úroveň kvůli malý rotacím. V tu chvíli proběhne "velká rotace"; aktivní a expired pole jsou prohozena a celý proces začne od začátku.
Stávající plánovač se snaží určovat interaktivní úlohy pomocí sledování, jak často procesy spí; ty, u kterých je vysledována interaktivita, jsou pak odměněny navýšením priority. RSDL tohle vše ruší. Místo toho procesy, které spí, prostě nevyužijí všechen svůj přidělený čas na vyšších úrovních. Když běží, jsou přirozeně ve výhodě oproti konkurenci, která baží po procesorovém čase. Pokud proces prospí malou rotaci, vrátí se jeho příděl na hodnotu určenou pro danou prioritu ve frontě. Takže bude moci běžet s vysokou prioritou, i když ostatní procesy s vysokou prioritou, které během té doby běžely, byly při malých rotacích odstrčeny na úrovně s nižší prioritou. To vše dohromady by mělo interaktivním aplikací zajistit rychlé reakce.
Několik výkonnostních testů, které připravil Con, ukazuje, že systémy běžící s RSD si vedou o trochu lépe než běžný plánovač z 2.6.20. První zprávy testerů byly pozitivní, přičemž jeden člověk dokonce prosazoval zařazení RSDL do 2.6.21. To se v tuto fázi vývojového cyklu nestane, ale Linus je nakloněn začlenění RSDL v budoucnu:
Souhlasím, částečně i proto, že reakce zatím byly nadšené, ale především to vypadá, že s tím jde daleko lépe uvažovat o chování - věc, se kterou byly vždy problémy při tom posilování priorit s historií stavu procesů.
Con se nedávno nechal slyšet, jak těžké je prosadit vylepšení interaktivity do hlavního jádra. Tentokrát bude možná s vývojem událostí spokojenější.
O správě paměti se za dobu existence jader řady 2.6 příliš nemluvilo. Mnohé z nejhorších problémů byly vyřešeny a hackeři, kteří se správou paměti zabývali, se začali věnovat jiným oblastem. To však neznamená, že by nebylo nic na práci; naopak, věci možná naberou rychlý spád. Několik nedávných diskuzí může přiblížit, co by mohlo v budoucnu vést k obnovenému zájmu o toto téma.
Patche Mela Gormana, které řeší předcházení fragmentaci paměti, tu už byly probírány. Hlavní myšlenkou Melovy práce je určení stránek, které lze snadno přesunout nebo získat zpět, a jejich následné seskupení. Přesunutelné stránky zahrnují ty, které byly alokovány pro uživatelský prostor; přesunutí je pouze otázkou změny příslušných záznamů v tabulce stránek. Stránky, které lze získat zpět, jsou jaderné keše, jež lze v případě potřeby uvolnit. Seskupování těchto stránek jádru dovoluje uvolnit velké bloky paměti, což je užitečné pro umožnění alokací vyššího řádu [high-order allocations] nebo pro úplné uvolňování celých oblastí paměti.
V minulosti se lidé, kteří Melovy patche prohlíželi, neshodovali v tom, jak by měly fungovat. Někteří prosazují udržování samostatných seznamů uvolněných míst pro různé druhy alokací, zatímco jiní jsou přesvědčeni, že pro takové rozdělování paměti byl vytvořen systém zón. Takže tentokrát Mel připravil dvě sady patchů: seskupovací mechanismus založený na seznamech a novou zónu ZONE_MOVABLE, která je omezena na přesunutelné alokace.
Rozdíl je v tom, že oba patche jsou teď navrženy tak, aby spolupracovaly. Ve výchozím stavu není žádná zóna přesunutelná, takže mechanismus založený na seznamech se o udržování alokací pohromadě stará sám. Administrátor může nastavit použití ZONE_MOVABLE při bootu pomocí parametru kernelcore= - ten určuje množství paměti, které do zóny nemá být vloženo. Kromě toho Mel poslal souhrnné informace o tom, jak je při použití těchto patchů ovlivněn výkon. Mel se také odhodlal k jednomu neobvyklému činu: součástí prezentace jsou i videa, která ukazují, jak alokace paměti reagují na zátež systému při použití různých alokačních mechanismů; obrázek vpravo je jeden snímek z těchto videí. Demonstrace je to přesvědčivá, ale jeden aby se teď bál, že budou k začlenění patchů do jádra od nynějška potřeba multimediální prezentace.
Tyto patche už si každopádně našly cestu do jádra -mm, i když Andrew Morton pořád nemá jasno v tom, jestli stojí za to nebo ne. Kromě jiného má starosti kvůli tomu, jak si budou rozumět s dalšími věcmi z této oblasti - především jde o hot-plugging paměti [přidávání a odebírání za chodu] a paměťové limity jednotlivých kontejnerů. Ačkoliv patche řešící obě tyto funkce už existují, nejsou tak daleko, aby už bylo možno začít začleňovat do jádra. Tato diskuze Mela a Andrewa stojí za přečtení, pokud vás téma zajímá.
"Horké" [za běhu] odstraňování paměti by určitě mohlo z Melovy práce těžit - paměť, kterou je potřeba dát pryč, může být omezena na přesunutelnou a uvolnitelnou, což umožní její vyprázdnění v případě potřeby. Ne každý si však myslí, že by hot-plugging byla užitečná funkce. Hlavně Linus je proti. Největší potenciál má hot-plugging při virtualizací; hypervizorům umožňuje podle potřeby přesouvat paměťové zdroje mezi hosty. Linus poukazuje na to, že většina virtualizačních mechanismů už má metody pro přidávání a odstraňování jednotlivých stránek hostů; není tedy nutné mít další podporu.
Další možné využití této techniky je pro šetření energií pomocí vypínání paměti, když není potřeba. Je jasné, že musí být možné přesunout z bloku všechna potřebná data, má-li být vypnut. Linusův názor byl ještě více zamítavý:
Všechny ty řeči o napájení DRAM jsou pohádky pro důvěřivé děti. Nenechte se nachytat. Není to reálné. Hardwarová podpora NEEXISTUJE a pravděpodobně ještě několik let existovat nebude. A skutečné řešení je stejně jinde...
Máte-li zájem, tak další informace o jeho námitkách najdete v konferenci. Ve zkratce: Linus si myslí, že by dávalo mnohem více smyslu zkoumat možnosti vypínání celých NUMA uzlů místo jednotlivých pamětí. Přesto však Mark Gross poslal patch umožňující vypnutí paměti, který obsahuje nějaké základní anti-fragmentační techniky:
PM-memory [Power Managed memory = správa napájení paměti] nebude užitečná, pokud nemáte zátěže, které by ji mohly využít. A nejedná se o desktop. Nicméně, existuje určitý počet uživatelů, kvůli kterým stojí za to ty patche v komunitě prosazovat. Tyto zátěže se většinou vyskytují u součástí sítě, kde využití paměti kopíruje provoz.
Objevila se i myšlenka, že rezidentně nastavené limity velikosti [resident set size limits] (obyčejně spojované s kontejnery) by mohly vyřešit dost stejných problémů jako anti-fragmentace. Rik van Riel v odpovědi namítal, že RSS limity by mohly zhoršit problémy se škálovatelností, kterými v současné době linuxový systém pro správu paměti trpí. To vyvolalo otázky od lidí jako Andrew, kteří o těchto potížích nevěděli. Rik reagoval několika poměrně nekonkrétními příklady; zjevně nemůže jít do podrobností kvůli dohodám se zákazníky, kteří se s těmito problémy setkávají.
To vedlo k samostatné diskuzi o tom, jestli má smysl se pokoušet o řešení problémů se správou paměti bez testovacích příkladů, které by dané problémy demonstrovaly. Rik tvrdí, že opravování příkladů často způsobuje nefunkčnost při reálném nasazení, na což Andrew odpověděl:
Nějak se mi nechce věřit, že by osoba nebo organizace, která není schopna připravit ani jediný příklad pro testování, dokázala takové problémy opravit, aniž by něco pokazila.
Ve snaze posunout diskuzi kupředu dal Rik dohromady stránku s popisem některých problémových zátěží.
Jedna z Andrewových připomínek se týká toho, že opravování problémů se správou paměti způsobených specifickými zátěžemi bude vždy obtížné; ne vždy má jádro informace o tom, které stránky budou brzy potřeba, a které je možné zahodit. Správným řešením by možná bylo usnadnit uživatelskému prostoru předávání informací o očekávaných nárocích. K tomuto účelu dal pro testování k dispozici nástroj pro správu keše stránek. Funguje jako knihovna LD_PRELOAD, která zachycuje systémová volání týkající se souborů, sleduje aplikace a říká jádru, že má z keše vyhodit stránky po té, co byly použity. Výsledkem je, že běžné operace (například kopírování stromu jádra) mohou být provedeny, aniž by byla z keše vytlačena jiná užitečná data.
Některé reakce byly skeptické, ale také se lidé zajímali o to, jak by do nástroje mohla být přidána chytřejší pravidla šitá na míru aplikacím. Například pravidlo pro zálohovací nástroje by výstupní soubor z paměti vyhodilo okamžitě a sledovalo by stránky čtené z jiných souborů a hned by je zase vyhazovalo - ale jen pokud by už v paměti nebyly - atd. Zůstává otázkou, jestli tento nástroj někdo vyzkouší při řešení skutečných zátěžových problémů, ale potenciál tu je. Jádro není vždy ten nejchytřejší.
Rozhraní pro sledovací [tracing] programy v Linuxu je systémové volání ptrace(). Používá se hlavně v debuggerech, ale najdou se i jiné aplikace; například User-mode Linux může používat ptrace(). Rozhraní sice svou práci odvede, ale je jen málo systových volání, která jsou terčem větší kritiky. ptrace() má celou řadu nedostatků, jeho rozhraní se vývojářům v uživatelském prostoru špatně používá a vývojářům jádra špatně spravuje. Kromě toho je neefektivní a během let bylo zdrojem nejednoho bezpečnostního problému. Přesto ptrace() přežívá; je to součást uživatelského API a nic lepšího k dispozici není.
Brzy se však možná objeví lepší alternativa v podobě patche "utrace" (autorem je Roland McGrath), který je v tuto chvíli v -mm. Utrace zcela nahrazuje ptrace(), ale zachovává pro uživatelský prostor stejné rozhraní. Jako takové je to tedy užitečné pročištění složitého systémového volání. Skutečná hodnota utrace se však pravděpodobně projeví v budoucnu u nových sledovacích rozhraní.
Základní kód utrace s uživatelským prostorem vůbec nemluví; je to jaderné API, které lze použít k vybudování jaderných sledovacích mechanismů. Tyto mechanismy jsou založeny na konceptu "sledovacího enginu", který je definován běžnou strukturou plnou ukazatelů na metody. Struktura (struct utrace_engine_ops) má čtrnáct zpětných volání, z nichž každé se týká něčeho, co sledovaný proces může udělat nebo udělal. Jedno zpětné volání jako příklad:
u32 (*report_syscall_entry)(struct utrace_attached_engine *engine,
struct task_struct *tsk,
struct pt_regs *regs);
Kdykoliv sledovaný proces vyvolá systémové volání, obdrží sledovací engine (pokud si o tuto událost řekl) volání na své zpětné volání report_syscall_entry(). K volání dojde "bezpečnou" dobu předtím, než je provedeno systémové volání; nejsou drženy žádné zámky a sledovací proces může bezpečně přistoupit ke stavu sledovaného procesu. Zpětné volání vrátí bitmasku, která určuje, co se stane dál; bitmaska může změnit stav sledování, odpojit engine, ukrýt událost před dalšími sledovacími enginy a ještě více.
Sledovací engine je spuštěn pomocí:
struct utrace_attached_engine *
utrace_attach(struct task_struct *target, int flags,
const struct utrace_engine_ops *ops,
unsigned long data);
Toto volání připojí engine k danému target procesu. Ke kterémukoliv procesu lze připojit i více enginů - výrazný rozdíl oproti ptrace(). Nově připojený engine vlastně nic nedělá, dá se o něm říci, že je v klidovém stavu. Nastartování enginu vyžaduje jeden nebo více akčních příznaků:
int utrace_set_flags(struct task_struct *target,
struct utrace_attached_engine *engine,
unsigned long flags);
Existuje speciální parametr (UTRACE_EVENT(QUIESCE)), který cílový proces uvede do stavu nečinnosti. Obecně je před operováním s úlohou nejprve nutné nastavit tento parametr a pak počkat na zpětné volání (enginové metody report_quiesce()), které oznámí, že je proces opravdu zastaven. K dispozici je celá sada dalších událostí, které lze vyžadovat: fork [rozdělení], exec [spuštění] nového programu, přijetí signálu, smrt procesu, vstup a konec systémového volání atd. Krokování instrukcemi a bloky programu se také řeší přes mechanismus událostí.
Pomocí následujícího kódu je možné cílovému procesu vnutit signál:
int utrace_inject_signal(struct task_struct *target,
struct utrace_attached_engine *engine,
u32 action, siginfo_t *info,
const struct k_sigaction *ka);
Takto odeslané signály jsou cílovému procesu doručeny okamžitě; nejsou zařazovány do fronty jako obvykle.
Utrace API toho nabízí víc než je v tomto stručném přehledu popisováno - včetně API pro popis a práci s registry procesoru; vizte skvělý dokumentační soubor, který je k patchům přiložen. Součástí je i kompletní reimplementace ptrace() postavená na utrace.
Reimplementace ptrace() však tolik zajímavá není, i když jde o velké zlepšení. Hlavním účelem utrace je snaha inspirovat k vytváření nové generace uživatelských API pro sledování procesů a ještě více. Roland k tomu řekl:
Utrace API není určeno pouze k tomu, abych měl možnost napsat skvělé nové uživatelské API, které by nahradilo ptrace. Hlavním důvodem je snaha o to, aby se psaní nového uživatelského debuggovacího nástroje přiblížilo psaní softwarového ovladače zařízení, souborového systému nebo síťového stacku - aby mohlo více lidí přicházet s novými nápady, aniž by u toho riskovali zdravý rozum. Utrace se postará o ty nechutné nízkoúrovňové implementační otázky a umožní různým nesouvisejícím nástrojům koexistovat, aniž by si navzájem překážely.
Jinými slovy, ačkoliv by utrace nakonec mělo umožnit odstranění ptrace(), je v tom mnohem více možností. Pokud se dostane do hlavního jádra, těšte se na zajímavé věci v mnoha oblastech.
29.3.2007 17:51
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
napájecí napětí je pod 2VToho bych se bál. U DDR to bylo 2,6V a u DDR-II bych pod 2V nešel (pod 2,3V mi to jede nestabilně). Ale jinak souhlasím s tím, že vypínání pamětí u běžného PC moc velká úspora nebude.
29.3.2007 19:06
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
29.3.2007 23:33
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Někde jsem četl, že se to může chovat jinak, když jsou pohromadě 4 moduly, ale kdo ví...Možná že když máš víc modulů, dojde k nějakému úbytku napětí kvůli většímu odběru proudu a nakonec tam zůstane těch 1.9V, přestože BIOS tvrdí 2.3V
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
29.3.2007 08:54
