Jaderné noviny - 7. 6. 2006

20. 6. 2006 | Robert Krátký

Články - Jaderné noviny - 7. 6. 2006  

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: 2.6.16.20

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í.

Citát týdne: Alan Cox

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

Co nebude v 2.6.18

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ý.

• Ovladač acx100 podporuje dost bezdrátových čipsetů, ale bohužel se objevily připomínky k tomu, jakým způsobem byl vyvinut, a jestli by jeho začlenění nezpůsobilo Linuxu právní problémy. Dokud se tato otázka nevyřeší, ovladač bude u ledu.
• Patche pro počítání doby, po kterou úlohy čekají, jsou na hraně. Hlavním zádrhelem je v tomto případě vytvoření nového rozhraní, pomocí kterého lze z jádra získávat informace o úlohách. Veškerý nový kód, který bude exportovat tento druh informací (a pár patchů už existuje), by měl toto API používat. Takže možná bude snaha vše ještě více zkontrolovat a prodiskutovat. Ze stejných důvodů nebude tentokrát pravděpodobně zařazen ani podobný patch který řeší statistiky netýkající se úloh.
• eCryptfs také nemá jisto. Tento souborový systém implementuje vlastní mechanismus pro stackování nad základním souborovým systémem. Ale člověk, který kód kontroloval, by raději viděl vytvoření obecné stackovací vrstvy, kterou by mohl používat kdokoliv. Na podobnou potíž často narážejí lidé, kteří chtějí přidat novou funkci; žádá se od nich vytvoření obecnější infrastruktury. Úmysl je to dobrý, ale může být příčinou zdržení a další práce.
• Patch se jmennými prostory UTS. Implementuje malou část kontejnerového konceptu, ale sám o sobě příliš užitečný není. Takže asi počká, až bude připraveno více kontejnerové infrastruktury.
• Přizpůsobivé přednačítání je považováno za příliš čerstvé. Některé výkonnostní testy ukazují výrazné zvýšení výkonu díky těmto patchům, jiné tak jasné nejsou.
• Reiser4. Andrew: S tímhle musíme něco udělat. Je nutná pečlivá kontrola, ale není moc lidí, kteří na to mají dost zkušeností, a ještě méně těch, kteří by měli čas. Pomohlo by, kdyby se věci ujal nějaký distributor. Tento souborový systém čeká bokem už velmi dlouho, ale začlenění stále není na obzoru.
• Obecná IRQ vrstva se prý "ještě stabilizuje" a je pravděpodobnější, že půjde až do 2.6.19. Totéž platí pro validátor zámků.

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.

Konec napájení přes USB

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:

1. Spusťte lsusb -v a vyhledejte záznam o zařízení, které vás zajímá. Například moje USB myš je popsaná takto: Bus 001 Device 003: ID 046d:c01b Logitech, Inc. MX310 Optical Mouse. Myš je zapojena do hubu, který je o kousek dříve popsán jako "Bus 001, Device 002". Dohromady dávají tato čísla umístění "1-2.3". Toto číslo je důležité.
2. Pod zařízením s tímto číslem je k nalezení jedna nebo více možných konfigurací, včetně přiřazených požadavků na napájení. Každá z těchto konfigurací obsahuje číslo bConfigurationValue. Je potřeba nalézt číslo požadované konfigurace. Často je to 1.
3. Vynuťte si konfiguraci zařízení následujícím příkazem:

       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.

SMPnice

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.

Diskuse k tomuto článku

[Nikola Ciprich]

to bych asi neprekladal, z prekladu mi sotva doslo o co jde - tzn o podporu vibraci u ruznych gamepadu atd, v cestine jsem nikdy neslysel nic jineho nez puvodni anglicky termin force-feedback...

[Robert Krátký]

Máš pravdu. Já jsem si při čtení vůbec neuvědomil, o co se jedná - jinak bych to nepřekládal.

[s0]

ad napajeni USB: sice tomu prd rozumim, ale je to fakticky supr vlastnost. Takze predpokladam, ze tedy budu tahat k modemu jeste sestitunovej napajeci kabel. Jen tak dal...

[Aleš Kapica]

To je fakt "chytrý" kec. Pokud jsi dobře četl, tak korektně udělaný hardware problém mít nebude. Pouze ten, který na nějaké specifikace zvysoka prděl. Ale stále nastavení kernelu lze přebít, pouze musíš vědět jak. Pokud jsi četl vše, tak víš.

[s0]

ehm, ja si tu specifikaci modemu bohuzel precetl.

[Aleš Kapica]

Klidně si ji přečti ještě jednou, stejně ti to k ničemu nebude. Pleteš si totiž jabka s hruškama. Pokud se ten modem připojuje přes USB kabel a parametry tohoto připojení neodpovídají technické specifikaci pro rozhraní USB tak to znamená jen, že sis pořídil pěkný šmejd.

[s0]

a tvrdil jsem neco jineho? Akorat "ted to proste facha (tm)". ale co uz, nejak se s tim vyporadam.

[Václav HFechs Švirga]

Až ti nějaký čínský modem (tm) odškvaří USB řadič, tak začneš nadávat že ti Linux zlikvidoval základovku a že to měli kontrolovat? Ach jo :(.

[dejfson]

debatujete od veci. S napajenim pres USB je to trochu jinak. Pokud zapojite neco do USB slotu, dojde k tomu, ze pocitac by MEL limitovat odber proudu pripojeneho zarizeni na 100mA. Po zapnuti hardwaru je tedy k dispozici zdroj 5V@100mA max. Pak dochazi k druhe fazi pripojovani, ktere se rika enumerace. Behem enumerace PC zjisti jake ma HW proudove naroky a v okamziku kdy se ti dva dohodnou (tedy PC ma k dispozici danny vykon a zarizeni jej vyzaduje), pak odber zarizeni _MUZE_ stoupnout az na 500mA, coz pokryje proudove naroky vetsiny zarizeni. Nicmene dulezite je, aby DOSLO k enumeraci zarizeni, tj. aby PC VEDELO jaky typ zarizeni je pripojeny. V okamziku kdy k enumeraci nedojde, standardne by se melo vypnout i napajeni 5V@100mA.

-- Shrnuto a podtrzeno: systemy ktere enumeraci maji (modemy, usb mass storage apod) - tech se to nedotkne vubec. LED lampy - tady je trochu problem protoze vetsinou jsou to jenom stabilizatory proudu bez enumerace, tedy by mely fungovat ty, ktere odebiraji min jak 100mA - ovsem v zavislosti na systemu. Jestli jsem to pochopil spravne, tak v novem jadre se budou vypinat.

vsechno je popsano ve specifikaci USB. zarizeni ktere se tou specifikaci neridi jsou nestandardni a tudiz nemuzete ocekavat ze budou fungovat na vsech systemech.

[s0]

v tom pripade neni co resit. supr.

[Peter Golis]

uz sa tesim ako budem citat recenziu na usb gadget - ventilator - ktory bude koli odberu vyhovovat usb specifikacii. a to sa priaznivo prejavi na jeho cene, najme pre jeho vyrobcu.
co dodat, predsa len bol ten krok potrebny

[dejfson]

ale no tak. chip pro enumeraci usb (napr TUSB, EZUSB) stoji v kusovem mnozstvi par euro. V tisicovych nakladech par centu. Na cene vyrobku se to drasticky neprojevi. Problem je v tom, ze se asi tak o 2 tydny prodrazi vyvoj produktu. Pri dnesnich trendech vylezt na trh s necim co jeste neni hotove se slovy 'vsak si ze zakaznika udelame beta-testera' to je ovsem neprekonatelna prekazka.

[Peter Golis]

moj prispevok mozno vyzeral ironicky, ale myslel som ho vazne. ja osobne by som rad vlastnil usb ventilator ktory je identifikovany operacnym systemom ako usb ventilator. a navyse zo zarukou ze mi nezlikviduje polovicu maticnej dosky. to ze kazda vec navyse ktora nie je nevyhnotne potrebna k funkcionalite sa prejavi na cene, je jasne. takze kazdy pravny subjekt ktory si pridava marzu sa zvyseniu ceny potesi, ak ovsem nebude to zvysenie neunosne. ale to sa uz netyka kategorii gadget.

[Michal Vyskočil]

Anebo se (za velkého nadávání) ujmeš napsání příslušného udev pravidla

[Hynek (Pichi) Vychodil]

ad napajeni USB: sice tomu prd rozumim, ale ...

Toho se drž, tímhle způsobem si naděláš spoustu kamarádů a budeš hvězdou každé společnosti

[s0]

byt oblibenym kverulantem je me druhe ja ;)

[trekker.dk]

Pokud nechceš tahat napájecí kabel, můžeš si pořídit přídavnou kartu s USB porty, která bude schopná dodat dostatečný proud.