Portál AbcLinuxu, 29. dubna 2024 18:35
Aktuální verze jádra: 2.6.16.20. Citát týdne: Alan Cox. Co nebude v 2.6.18. Konec napájení přes USB. SMPnice.
Aktuální verze jádra je 2.6.16.20, vydaná 5. června. Opravuje několik závažných problémů, z nichž však žádný se pravděpodobně netýká bezpečnosti.
Aktuální předverze je 2.6.17-rc6, vydaná 5. června. Objevilo se dost oprav na to, aby Linus vydal ještě jednu -rc. Podrobnosti v dlouhém changelogu.
Do hlavního repozitáře nebyly od -rc6 začleněny žádné patche.
Aktuální -mm strom je 2.6.17-rc6-mm1. Mezi nedávné změny patří vylepšená podpora force-feedbacku ve vstupním ovladači a velký počet patchů týkajících se validátoru zamykání.
Dříve to fungovalo tak, že byly věci připraveny do zhruba správného stavu, začleněny do stromu a pak testovány. Dneska všichni blokují cokoliv, co je jen lehce nedokonalé, takže je nemožné do stromu přidat něco většího, protože to *nikdy* nebude dokonalé, dokud nedojde k začlenění, aby na tom mohli lidi hackovat, a nikdy to nebude dokonalé pro všechny.
Perfekcionismus je nepřítelem pokroku a úspěchu. Riskujeme návrat do situace, která nastala s 2.4, kdy bylo tak těžké něco začlenit, že většina prodejců distribuovala jádra, která neměla nic společného s tím oficiálním. Tentokrát je to pravděpodobně horší o to, že neexistuje žádný společný "neoficiální" strom jako -ac, takže budou dodávat různé varianty a kombinace.
-- Alan Cox
Vývojový cyklus jádra 2.6.17 se chýlí ke konci, přičemž finální verze vyjde zřejmě ještě před polovinou června. Je tedy přirozené, že se pozornost vývojářů obrací k 2.6.18. Všem pro zamyšlení nad tím, jak to bude probíhat, zveřejnil Andrew Morton shrnutí plánu začleňování do 2.6.18, ve kterém popisuje svou představu o tom, jak naložit s věcmi čekajícími v -mm. Místy se mluvilo o verzi, která by sloužila pouze k opravování chyb, ale je jasné, že 2.6.18 to nebude - hodně patchů je určeno k začlenění.
Funkce, u kterých se očekává začlenění, jsou zajímavé, ale je lepší o nich mluvit ve chvíli, kdy se dostanou do hlavního stromu; do té doby zůstává jejich osud nejistý. Takže prozatím postačí říci, že 2.6.18 bude pravděpodobně obsahovat souborový systém S/390, několik patchů pro správu paměti, vylepšení software suspend [uspání], nový subsystém pro hardwarové hodiny na i386, vylepšení plánovače SMP, patche pro přednahrávání [prefetch] swap (možná), futexy s dědičnou prioritou, přepracovaný kód /proc/pid, několik vylepšení MD (RAID), nové jaderné API inotify a kód ze stromů subsystémů, který se neobjevuje přímo v -mm. Jak je zvykem, pohrne se do hlavního stromu před novou verzí spousta kódu.
Může však být zajímavé se také podívat na to, co začleněno nebude. Podle Andyho zprávy to vypadá, že následující velké sady patchů budou vynechány:
Je spousta kódu, který by potřeboval, aby se na něj podívali správci různých subsystémů. Andrew o něm říká: Mám pořád dost problém s tím, že ten materiál nikdo nezpracovává. Pokusí se dostat ze správců nějaké odpovědi, ale některé patche budou asi i nadále čekat.
Jde také o ovladače, kterým podle některých trvá moc dlouho, než se dostanou do jádra. Vypadá to, že laťka je nastavena příliš vysoko. Vždycky se najde něco ke kritizování, ale občas je lepší pokračovat s tím, co je, a postupně věc zlepšovat. Lidé, kteří kontrolují kód, často trvají na dokonalosti a brání začlenění dobrému kódu, který by mohl být uživatelům Linuxu užitečný.
To vše může být jinak, až se začne se začleňováním. Vývojáři obhajují konkrétní patche; například Ingo Molnar žádá o další zvážení u obecné IRQ vrstvy a validátoru zámků. V příštích týdnech se dočtete o tom, jak to nakonec dopadlo.
Chyby v jádře jsou špatné zprávy. Mezi ty nejhorší patří regrese - situace, kdy dojde k tomu, že dříve funkční systém přestane fungovat po upgradu. Vývojáři jsou vůči regresím čím dál více nekompromisní; patche, které naruší funkčnost systému, jsou většinou vyhozeny, i když opravují jiné problémy. Myšlenka, kterou prosazuje Linus, říká, že když jednou systém funguje, měl by fungovat i v budoucnu.
Stalo se však, že několik uživatelů USB mělo po upgradu na 2.6.16 nefunkční systém. Ale v tomto případě to vývojáři nepovažují za regresi a je nepravděpodobné, že by došlo ke změně. Jde o dobrou ukázku kompromisů, které musí dělat vývojáři operačních systémů.
USB porty mohou dodávat energii připojeným zařízením; využívají to jak periferní zařízení, tak věci jako třeba LED lampičky. Množství energie, kterou lze dodávat, je však omezené. USB zařízení hostiteli sdělí svou aktuální spotřebu a ten se pak může rozhodnout, jestli má požadovanou kapacitu k dispozici nebo ne. Pokud k dispozici dostatek energie není, zařízení nebude umožněna konfigurace a provoz.
USB specifikace obsahuje hodně pravidel popisujících, jak by měla fungovat konfigurace napájení. Jedno z nich se týká nenapájených hubů - těch, které nemají vlastní zdroj napájení. Celkový proud odebíraný nenapájeným hubem nesmí přesáhnout to, co může hostitel dodat; konkrétně jsou zařízení na nenapájených hubech USB specifikací limitována na 100 mA. I kdyby byl využit jen jeden port hubu, i ten by byl omezen na tuto hodnotu, přestože v takové situaci by měl fungovat i větší odběr.
Před 2.6.16 linuxové jádro nekontrolovalo požadavky na napájení před konfigurací zařízení. Od 2.6.16 však nebude povolena konfigurace na nenapájeném hubu žádnému zařízení, které vyžaduje více než 100 mA. Takže zařízení, která dříve tímto způsobem fungovala, s novým jádrem nemohou být provozována; ne všichni uživatelé jsou z toho zrovna nadšeni.
Argumentuje se tím, že vzhledem k tomu, že ve skutečnosti tato zařízení téměř vždy fungují, nemělo by je jádro odstavovat. Platí však, že provoz hardwaru mimo dané specifikace je vždy nebezpečný. Často to projde, ale někdy může dojít k nehezkému selhání. Poměrně velká skupina USB zařízení jsou mass storage [úložná]; problémy s napájením by u tohoto druhu zařízení mohly způsobit vadná data a poškození hardwaru. Takovým důsledkům nechtějí vývojáři uživatele vystavovat, takže raději odmítají provozovat zařízení nad rámec specifikací.
Pro vývojáře není skutečnost, že dříve funkční hardware teď nefunguje, regresí. Jde o opravu chyby, protože jádro teď konečně provádí kontrolu, kterou mělo umět už dávno. Nechystají se to tedy nijak měnit.
Nicméně, je možné jádro přesvědčit, aby se neřídilo svým přesvědčením, a zařízení i tak konfigurovalo. Není to však snadné. Kroky by vypadaly takto:
echo -n 1 > /sys/bus/usb/devices/1-2.3/bConfigurationValue
Konfigurační hodnoty a cesta k zařízení musí být nahrazeny
skutečnými hodnotami zjištěnými z výstupu lsusb.Není třeba říkat, že tento postup není úplně nejsnazší - a je nutné jej opakovat při každém připojení zařízení. Pro ty, kterým nečiní problémy psaní udev pravidel, je automatizace takové konfigurace hračkou. Možná budou jednou desktopová prostředí natolik chytrá, že tuto situaci rozpoznají a nabídnou (s příhodně odstrašujícím varováním) u některých zařízení přebití jádra. Možná je však lepší prostě koupit napájený hub nebo zapojit zařízení přímo do hostitele.
Na linuxovém plánovači [scheduler] pro víceprocesorové systémy bylo odvedeno hodně práce. Kdykoliv to dává smysl, plánovač přehodí procesy z jednoho procesoru na druhý, aby zůstávaly srovnatelně vytížené (přibližně). Ale protože přesun procesu obnáší jistou režii, snaží se plánovač přesunování vyhýbat. Výkon SMP byl v raných verzích 2.6 problematický, ale posledních pár let je rozumně solidní.
Existuje však situace, při které současný plánovač nefunguje tak dobře, jak bychom rádi. Představte si jednoduchý systém s dvěma procesory. Pokud jsou na tomto systému spuštěny dva procesy s normální prioritou a oba míří na CPU, plánovač nakonec spustí každý z nich na jiném procesoru. Jsou-li potom spuštěny dva "niceované" (s nízkou prioritou) procesy (také směřující na procesor), člověk by předpokládal, že se plánovač postará o to, aby tyto procesy dostaly méně procesorového času než ty s normální prioritou.
Když jsou procesy rozděleny tak, že na každém procesoru skončí jeden s normální a jeden s nízkou prioritou, tento předpoklad se vyplní; procesy s nízkou prioritou získají relativně málo procesorového času. Je však stejně dobře možné, že oba procesy s normální prioritou skončí na jednom procesoru, zatímco na druhém budou oba s nízkou prioritou. V takovém případě budou dva procesy s normální prioritou soupeřit o jeden procesor, kdežto ty s nízkou o druhý. Výsledkem bude, že procesy s nízkou prioritou dostanou stejně procesorového času jako ostatní, bez ohledu na jejich sníženou prioritu. Tak si to uživatel určitě nepředstavoval, když priority nastavoval.
Potíž je, že plánovač se dívá pouze na délku fronty u každého procesou, priority nebere v potaz. Takže v obou zmíněných případech se procesory zdají být srovnatelně vytíženy a nedojde k žádnému přerozdělování. K napravení tohoto problému je potřeba, aby kód starající se vyvažování zátěže rozuměl tomu, že ne všechny procesy jsou si rovny.
Řešení lze nalézt v sadě patchů "smpnice", kterou implementoval Peter Williams s pomocí mnoha dalších vývojářů. Kód smpnice mění vyvažování zátěže tak, že nezkoumá pouze délku fronty. Místo toho je každému procesu přiřazena "zátěžová váha", která je odvozena z priority. Když probíhá rozhodování o vyvažování zátěže, porovnává plánovač celkovou zátěžovou váhu místo délky fronty. Je-li zjištěna nerovnováha zátěže, přesune plánovač proces, aby se věci opět srovnaly. Je-li nerovnováha velká, bude přesunut proces s vysokou prioritou; při malém rozdílu se přesouvá proces s nízkou prioritou.
Základní myšlenka dává smysl, ale tahle sada patchů byla vyvíjena velmi dlouho. Plánovací kód je plný jemných heuristik, které lze snadno rozhodit. Dřívější verze smpnice proto způsobovaly výkonnostní regrese a setkávaly se s mnoha obtížemi. Například procesor, na kterém běží proces s velmi vysokou prioritou, se bude jevit jako nejvíce zatížený, přičemž výsledkem je, že mezi ostatními procesory na systému už nebude vyvažování probíhat. Tento problém byl vyřešen ignorováním procesorů, které nemají žádné přesunutelné procesy. Některé vyvažovací heuristiky, které by přesouvaly procesy s vysokou prioritou, přestaly fungovat, což způsobilo neoptimální plánovací rozhodnutí. Má-li teď proces nejvyšší prioritu na procesoru, je první na řadě k přesunutí. Byly také vychytány různé problémy se stabilitou, při kterých například procesy lítaly mezi procesory.
Díky všem těmto opravám se zdá. že kód smpnice začíná být stabilní, což by jej mohlo dostat do jádra 2.6.18. To by mělo usnadnit život lidem, kteří na SMP systémech provozují výpočetní zátěže s různými prioritami.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.