Jaderné noviny - 41/2007

16. 11. 2007 | Jirka Bourek | Jaderné noviny | 3557×

Měření výkonnosti plánovače procesů. Vyhnout se binárkám. GPL a embedded aplikace. 2.6.23-mm1, "Funguje o trošku lépe". Oprava deadlocku v NTFS. Odstranění iget() a read_inode(). Backportování ovladačů do jádra 2.4.

Obsah

• Měření výkonnosti plánovače procesů
• Vyhnout se binárkám
• GPL a embedded aplikace
• 2.6.23-mm1, "Funguje o trošku lépe"
• Oprava deadlocku v NTFS
• Odstranění iget() a read_inode()
• Backportování ovladačů do jádra 2.4

Následující obsah je © KernelTrap.

Měření výkonnosti plánovače procesů

10. říjen, originál

Alespoň na mém testovacím systému verze 2.6.23 poráží v sysbenchi verzi 2.6.22.9, reagoval Ingo Molnár na zprávu ukazující opačné výsledky. Odkázal na své vlastní (jpg) a popsal je:

Jak můžete vidět v grafu, ve verzi 2.6.23 je závislost na počtu klientů mnohem plynulejší. Verze 2.6.22 má malý (ale potenciálně statisticky nevýznamný) skok u 4 - 6 klientů, kdežto CFS má o něco lepší špičku (peak) (což je statisticky nevýznamné).

Ingo poznamenal, že nebyl schopen najít informace o tom, jak byl ten druhý benchmark proveden. Na té URL nejsou žádné .configy ani jiné detaily, které by se daly použít k preciznímu reprodukování jejich výsledků, takže přinejmenším malý bugreport by byl hezký. Poté nabídl několik informací o tom, jak sysbench pracuje, a několik doporučených voleb. Sysbench je celkem "dávkovaná" zátěž: nejvíc těží z dávkového plánování - klient udělá tolik práce, kolik může, pak server udělá tolik práce, kolik může, a tak dál. Čím déle může klient pracovat, tím cache-efektivnější zátěž je. Jakýkoliv odskok k serveru kvůli té otravné preempci jenom rozhodí stopu v cache zátěže a způsobí nižší propustnost.

Vyhnout se binárkám

10. říjen, originál

Nedávný pokus protlačit některé aktualizace V4L/DVB do jádra 2.6.24 se setkal s určitým odporem. Linus Torvalds shrnul problémy postihující video ovladač em28xx.

Mluvil jsem s různými lidmi a nikdo z hlavních vývojářů nebyl nadšen jádrem, které závisí na vnějších binárních blobech (binary large object, velký binární objekt) pro tunery.

Takže momentálně to vypadá tak, že ačkoliv bych osobně chtěl, aby více výrobců podporovalo své vlastní ovladače, tak jestliže to v tomto případě znamená, že bychom museli mít kvůli ladění karet neudržovatelné binárky v uživatelském prostoru, nikomu se to nelíbí.

Jako takový se starý a vyžilý ovladač em28xx zdá být pro mnoho lidí užitečnější, protože sám o sobě podporuje alespoň omezenou sadu hardwaru.

Andrew Morton dodal:

Dokud se ti nepodaří dostat ten nový ovladač do jádra (a podle diskuze z minulého měsíce to k tomu ani trochu nespěje), měli bychom dál udržovat starý ovladač. Pokud se rozhodneš se toho neúčastnit, pak musí ostatní dělat to nejlepší, co budou umět.

Co bychom neměli a nedovolíme, je, aby současný ovladač byl držen jako rukojmí při tvém pokusu vnutit kontroverzní a zjevně nevítanou změnu do stromu.

GPL a embedded aplikace

11. říjen, originál

Nejsou žádné "osoby zodpovědné za obranu GPL kernelu", je jenom pár set tisíc držitelů autorských práv k jádru a každý z nich má právo žalovat vás, pokud si myslí, že distribuujete něco, co porušuje jeho copyright. Tak Adrian Bunk reagoval na nedávnou diskuzi o legálnosti připojení GPL kódu do embedded aplikací. Dodal: jurisdikce a aplikovatelné autorské zákony závisí na více věcech, například kde vlastník autorských práv žije a kde kód distribuujete."

Na otázku, jak omezení daného hardwaru mohou ovlivnit interpretaci GPL, Theodore T'so odpověděl:

V konečném důsledku všechno záleží na tom, co je odvozené dílo. Pokud objektový soubor určený k připojení do kernelu je odvozené dílo, pak GPL zajišťuje, že infikuje i zbytek tohoto díla. Jestli tomu tak v tomto případě je nebo není, to je záležitost na další debatu. Pokud vím, žádný soud ještě nerozhodoval případ týkající se otázky objektových souborů, dynamického linkování a jestli jde o odvozené dílo nebo ne. Zdá se pravděpodobné, že odpověď se bude lišit od jednoho soudu k druhému. Tudíž jediná odpověď, kterou můžeme dát a která je užitečná, je: "nechoďte s tím do LKML a zeptejte se právníka."

2.6.23-mm1, "Funguje o trošku lépe"

13. říjen, originál

Andrew Morton zaslal svůj první -mm patchset proti nedávno vydanému jádru 2.6.23, čímž začal přípravu pro velké začleňování vybraných patchů do příštího jádra 2.6.24. Poznamenal k tomu:

Od rc8-mm2 jsem se hodně vyhýbal vkládání čehokoliv ve snaze stabilizovat věci kvůli spojení s 2.6.23.

To ale žádnému ze správců subsystémů nijak nezabránilo, aby nebláznili jako obvykle. Momentálně máme diff o velikosti 37 MB, ale zdá se, že funguje o něco lépe.

Oprava deadlocku v NTFS

13. říjen, originál

Tento update pro NTFS opravuje deadlock při připojení souborového systému. Během let byl oznámen už několika lidmi, ale teprve nedávno někdo, kdo ho hlásil, také reagoval na moje odpovědi a pomohl mi ho vypátrat (nikdy jsem nebyl schopen ho reprodukovat). Takto Anton Altaparmakov popsal patch pro souborový systém NTFS. Změny shrnul:

Oprava spočívala v nevolání ntfs_attr_set() při připojení, protože to způsobuje zavolání balance_dirty_pages_ratelimited(), která na systémech s málo paměti opravdu zkusí vyrovnat dirty stránky, přičemž se snaží zabrat semafor s_umount. Protože jsme ale stále ve fill_super(), ze kterého VFS drží s_umount pro zápis, dojde k deadlocku.

Špinavou práci nyní děláme ručně použitím samostatných bufferů. To má nepříjemnou "vlastnost", že připojování může trvat několik sekund, pokud je žurnál rozsáhlý, protože ho musíme celý vyčistit. Tohle by někdy někdo měl vylepšit tak, aby bylo vyčištěním žurnálu pověřeno pomocné jaderné vlákno, aby to bylo možné udělat na pozadí. Momentálně nemám čas to udělat sám a současné řešení funguje, takže to pro teď nechávám tak, jak je.

Odstranění iget() a read_inode()

14. říjen, originál

Tady je sada patchů, která odstraňuje všechna volání funkcí iget() a read_inode(), začal David Howells popis kolekce 32 patchů zaslané do lkml. Pokračoval objasněním důvodů, proč tyto funkce odstranit: Měly by být odstraněny ze dvou důvodů: za prvé neumožňují dobré ošetření chyb a za druhé jejich přítomnost znamená pokušení pro kód mimo filesystém volat iget(), aby získal přístup k inodům v tom filesystému. Také naznačil tři výhody:

(1) Ošetření chyb se zjednodušuje, protože lze vrátit chybový kód místo nutnosti volat is_bad_inode(). (2) Nyní lze rozeznat ENOMEM a EIO, které se objeví v cestě read_inode. (3) Kód by měl být menší. iget() je inline funkce, která se typicky volá dvakrát až třikrát v každém filesystému, který ji používá. Vložení kódu přímo do read_inode v každém souborovém systému eliminuje nějaké duplicity.

Backportování ovladačů do jádra 2.4

15. říjen, originál

Portoval jsem ovladač adutux pro zařízení z řady ADU z 2.6 do 2.4, oznámil Vitalij Ivanov v mailové konferenci Linux USB development. Maintainer verze 2.4 Willy Tarreau odpověděl, že přestože backport vypadá dobře, pravidlem je nezačleňovat nové ovladače do stabilní větve linuxového jádra 2.4. Verzi 2.4 momentálně používají lidé, kteří nechtějí/nemohou měnit, a lidé, kteří hledají téměř bezúdržbové jádro. Ovladače jsou často důvod, proč od 2.4 odejít, ne proč u něj zůstat.

Jedním z argumentů pro začlenění ovladače do hlavní řady stromu 2.4 bylo, že by se následně dostal do různých distribučních jader. Pete Zaitcev ale objasnil, že tímto způsobem to v enterprise jádrech nefunguje: minimálně v případě Red Hat Enterprise Linux takovéto backporty nikdy nebyly automatické. Do RHEL verzí 2.1 a 3 se už nové ovladače nedostávají vůbec, pouze opravujeme chyby, pokud se nějaké objeví. Realisticky, jádra 2.4 jsou prostě moc stará na to, aby je někdo používal. Willy souhlasil s tím, že zváží začlenění ovladače, pokud by se Vitalij stal oficiálním maintainerem backportu.

       

Komentáře

[Filip Jirsák]

• Co bychom neměli a nedovolíme, je, aby současný ovladač –> 1. čárka je navíc
• Tudíž jediná odpověď, kterou můžeme dát, a která je užitečná| je –> čárka má být i v místě, kam jsem přidal svislítko; osobně bych ani nedával čárku před „a“

Pak mám ještě pochybnosti o správném otečkování „pomohl mi ho vypátrat (Nikdy jsem nebyl schopen ho reprodukovat.)“ (dal bych v závorce malé písmeno a tečku až za závorku), ale to myslím nijak nevadí srozumitelnosti.

To je zajímavé, jak se člověk musí na obsah JN víc soustředit a víc si pak všímá chyb…

[trekker.dk]

K tomu prvnímu bodu - jsem přesvědčen, že se mýlíš.

[Filip Jirsák]

Vždyť je to jedna věta, ne? Co bychom neměli [a nedovolíme] je [to], … Myslím, že „je“ je v té větě předmět (rozvitý vedlejší větou).

[trekker.dk]

Podle mě jsou to obojí slovesa - když už jsi přidal to "to", tak tu větu přeskládám tak, aby to bylo vidět ještě líp: To, co bychom neměli a nedovolíme, je, aby se ovladač stal rukojmím. "Co bychom neměli a nedovolíme", je vedlejší věta, proto je oddělena čárkou. Stejně tak to platí i v originálu.

[Filip Jirsák]

jm nás roztrhá „je“ není přísudek samostatné věty – když tu vedlejší rozvíjející větu přepíšu přímo do větného členu, dostanu: „Co bychom neměli a nedovolíme je držení ovladače jako rukojmí.“ To „je“ není přísudek v samostatné větě. Ten váš příklad také není vedlejší věta, ale větný člen.

[trekker.dk]

jm nás roztrhá

Třeba ho už trefil šlak

když tu vedlejší rozvíjející větu přepíšu přímo do větného členu, dostanu: „Co bychom neměli a nedovolíme je držení ovladače jako rukojmí. To „je“ není přísudek v samostatné větě.“

Podle mě by to správně mělo být "Co bychom neměli a nedovolíme, je držení ovladače jako rukojmí.“ Protože i tu první rozvíjející větu lze přepsat do větného členu. "Nedovolitelné je držení ovladače jako rukojmí." Pokud by "je" nebyl přísudek, tak v téhle větě už jaksi přísudek chybí.

[Filip Jirsák]

Ale aby to byla věta, muselo by samotné „Co bychom neměli a nedovolíme“ dávat nějaký smysl. Podle mne ta slovesa „neměli“, „nedovolíme“ a „je“ tvoří přísudkovou část jedné věty. Zkusím se na to zítra podívat do chytrých knih

[trekker.dk]

Ale aby to byla věta, muselo by samotné „Co bychom neměli a nedovolíme“ dávat nějaký smysl.

Vedlejší věta sama o sobě smysl dát nemůže - "aby byl ovladač držen jako rukojmí" samo o sobě také smysl nedává.

Náš administrátor shledal tento komentář závadným.

off-topic

Zobrazit komentář

[Heron]

A pak že nejde v plain textu zvětšit font.

[Filip Jirsák]

Máma, která dělala jazykovou redaktorku, by tam čárku taky nedala. To ale platí jako argument nejvyšší asi jen u nás doma, vy asi budete chtít něco z těch chytrých knih S tím bude trochu problém, protože o psaní čárek jsem něco našel vlastně jen v Pravidlech. Souhlasím tedy, že to celé před „je“ je věta vedlejší (a to konkrétně „věta se vztažnými zájmeny kdo a co v roli podmětu“ dle Příruční mluvnice češtiny). Ovšem osobně bych na to stejně narouboval pravidlo „čárkou obvykle neoddělujeme výraz pociťovaný někdy jako výpustka, zejména není-li rozvit, nebo jen mírně (chápeme ho spíše jako holý vštný člen): četl bych, ale nemám co. – Přijdu, ale nevím, kdy.“ Nicméně to je už v oblasti „obvykle“, takže není chyba ani čárku napsat, ani ji nenapsat. Pak už zbývá jen neformální „pravidlo“ psát čárku tam, kde bych při čtení udělal malou pauzu. Příště budu opatrnější v tom, zda je to chyba, nebo bych to jenom sám napsal jinak.

Chválabohu za to, že i v IT existují články, kde se z jazykového hlediska diskutuje o tom, zde se má vědlejší věta oddělit čárkou i v případě, kdy z hlavní věty zbylo jen sloveso „být“. Vedle různých blogů a diskuzí, kde si pisatelé nelámou hlavu s vyjmenovanými slovy, shoda (nebo „schoda“) je nezajímá a čárky používají zřejmě ke grafickému zpestření textu, je to příjemné vybočení. Ale Robert myslím ví, že pravopisné diskuze pod články na Abíčku je kategorie o několik řádů jinde, než když je někomu potřeba pod blog napsat „piš prosím tě alespoň tečky na konci vět“

[petr_p]

První věta (Co bychom…) je věta vedlejší přísudková. Taková věta vyjadřuje jmennou část přísudku se sponou. Podobný příklad: Náš dědeček byl z těch, kdo šířili osvětu na venkově.

Je to trochu nezvyklé, protože při syntaktické analýze věty se jméno od spony neoděluje a považuje se za jeden větný člen. V tomto případě je ale jmenná část natolik rozvitá, že čárku bych považoval na místě.

[Filip Jirsák]

To jsem právě pořád nevěděl, zda je to podmět nebo část přísudku. Díky za vysvětlení.

[jm]

A uz je to tady zas. Fakt je neresitelny problem zridit si pod clankem link "Cestinarske blemcy" a presunout tyhle totalne off-topic veci tam?

Opravdu me vase reseni interpunkce pod clankem o kernelu naprosto nezajima.

[Robert Krátký]

Fakt je neresitelny problem zridit si pod clankem link "Cestinarske blemcy"

Bug #907

Opravdu me vase reseni interpunkce pod clankem o kernelu naprosto nezajima.

Tak tyhle komentáře n-e-č-t-i, hysterko.

[Filip Jirsák]

Proč se ptáte, zda je to neřešitelný problém, místo toho, abyste ten problém vyřešil? Mimochodem, můj komentář se článku týká, narozdíl od toho vašeho. Jestli vás moje komentáře nezajímají, tak se zaregistrujte a dejte si mne mezi blokované uživatele. Já už to s vámi udělal dávno. Myslím, že další debata s vámi je zbytečná.

[trekker.dk]

Pokud tě to nebaví číst, tak si sbal první vlákno, budeš mít po problému a nebudeš muset nadávat lidem, kteří se snaží o zkvalitnění obsahu.

[jm]

Bajecne, to je opravdu "reseni" jak stehno. Co takhle misto toho prestat konecne zasirat debatu pod clankem nesmyslnejma debata o predmetech, prisudcich, vetnych clenech apod.? Fakt je to tak tezke pochopit?

[Michal Kašpar]

Zaregistrujte se prosím, abych nemusel číst vaše příspěvky, které nejsou k tématu. Díky.

[Michal Vyskočil]

K blokování není registrace potřeba

[Michal Kašpar]

Jé, díky. Toho jsem si vůbec nevšiml.

[strby]

jo tak tohle me taky napadne pokazde kdyz si ctu kernelove novinky

[honza]

já bych taky radši viděl v komentářích u článku o jádru komentáře o jádru a ne o češtině.

[Jan Drábek]

Co jsem zkoušel CFS na mém postarším PC tak byl o kapánek horší než původní... Na novém stroji to zatím není moc poznat, spíš při záteži HDD je tuhej celej počítač (CFQ)...

Btw. Viděl jsem graf, kterým se chlubí FreeBSD 7.0, který se týkal vícevláknové práce MySQL a verze 2.6.22 byla o něco méně výkonější než FBSD 7.0, jádro 2.6.23 mělo výkonu tak tak polovinu.

[Jan Drábek]

Hmm, tak jsem si všiml, že právě na to reaguje ;)

[Milan Vančura]

Diky za dalsi "Jaderky". Lehce me zmatl nasledujici preklep, protoze mate i vyznam, tak posilam take jeden "patch"

s/nfs_attr_set/ntfs_attr_set/

[geebranz]

Groups are nice

cryotherapynashvilletn.com