Jaderné noviny 207

10. 3. 2003 | Leoš Literák | Jaderné noviny | 2936×

Panika kernelu v morseovce. FUSE 1.0. Reorganizace a urychlení /proc. Někteří uživatelé jsou nespokojeni s kódem psaným pod NDA. Petice za svobodné ovladače.

Do konference přišlo celkem 1847 emailů, nejvíce jich poslali Osamu Tomita, "David S. Miller", Andrew Morton.

Panika kernelu v morseovce, 6 e-mailů

Tomas Szepe zaslal patch pro zobrazení kernel panics v morseově kódu a zdůraznil jeho výhody:

• naprosto nezávislé na architektuře
• nezasahuje do atkbd (navrženo Vojtěchem Pavlikem).
• minimální změny do současného kódu
• zavádí oops v morseově kódu (NEJDŮLEŽITŠÍ!)
• užitečné pro lidi trávící většinu času v X

FUSE 1.0, 1 e-mail

Miklos Szeredi ohlásil:

FUSE vám umožní napsat si vlastní souborový systém jako obyčejný program. Má jednoduché, ale vyčerpávající uživatelské rozhraní a poskytuje snadný způsob vytvoření virutálního souborového systému jako aplikaci. Příkladem mohou být automatický měnič CD, vzdálený souborový systém pro kapesní počítače, náhled na databázi apod.

FUSE je určeno pro řadu 2.4. Instalace je snadná, není třeba patchovat ani rekompilovat. Dokumentace pro aplikační rozhraní a příklady jsou uvedeny v balíčku, který najdete na adrese http://sourceforge.net/projects/avf.

Reorganizace a urychlení /proc, 28 e-mailů

Ingo Molnar napsal:

Spousta lidí žádálo, aby se vlákna objevovaly v /proc, aby se mohli podívat na využití procesoru jednotlivými vlákny, obecně pro usnadnění ladění programů používajících vlákna. Velký problémem je velké zpomalení při spoustě vláken. Režie je tak velká, že například při 16 tisících vláknech je procps v podstatě nepoužitelné. Přitom existují uživatelé, kteří chtějí 50 tisíc vláken a více. Takže stav procfs a procps je nepřijatelný - proč používat top pro kontrolu systému, když překreslení jedné obrazovky zabere 22 sekund?!

Režie má dva důvody:

1. v jádře je velká režie při čtení rozsáhlých adresářů /proc, složitost spousty readdir() je O(N^2). Hlavní režie leží ve funkci get_pid_list(), která musí ve smyčce procházet přes rostoucí počet vláken, aby našel další várku PIDů.

   Abych opravil tento problém, zavedl jsem 'vyhledávací kurzor', který je kešován ve filp->private_data mezi voláními readdir(). Pokud kurzor souhlasí, pak můžeme přeskočit veškerou režii přeskočením vláken. Pokud kurzor není dostupný, pak se vrátíme k původnímu algoritmu.

2. Procps je nucen přečíst a zpracovat každé vlákno v /proc, aby byl schopen vytvořit přesné čítače využití procesoru procesem [process CPU usage]. Zpracování každého souboru /proc/PID/stat je nutné, protože statistiky procesoru jsou rozprostřeny mezi vlákny.

   Oprava se skládá ze dvou kroků. Nejdříve bylo nutné pro procps odlišit vlákna od procesů, aby nemusel procházet 16 tisíc adresářů. Vyřešil jsem to přidáním tečky před jméno souboru u vláken v adresáři /proc.

   • dma
   • kcore
   • 17031
   • .17074
   • .17075

   Klíčem je, že procps může projít vlákna, aniž by musel volat kernelové funkce 16 tisíckrát. Navíc tečkový přístup má další výhodu skrytí vláken při obvyklém ls /proc.

   Další změnou je možnost číst souhrné statistiky využití procesoru z hlavního vlákna [thread group leader]. Vytvořil jsem kvůli tomu čtyři nové položky v souboru /proc/PID/stat, jádro udržuje tyto informace aktuální při volání fork/exit a v přerušení časovače, takže to má velmi malou režii.

Přiložený patch vůči 2.5.62-BK implementuje tuto funkčnost. Alex Larsson upravil procfs pro tyto nové vlastnosti jádra, stahovat můžete z adresy http://people.redhat.com/alexl/procps/.

Provedl jsem nová měření výkonu. Při 16 tisících vláknech je jedno načtení stránky příkazu top 130-krát rychlejší. Jednoduché ps je 340-krát rychlejší. Dokonce i ps -axm, které zobrazuje všechna vlákna, je o něco rychlejší, díky kurzoru.

Další výhodou patche je plná kompatibilita se starým jádrem a nové procps je plně kompatilní se starými jádry. Navíc je vše zakódováno jako ASCII, nejsou použity žádná binární rozhraní.

Linus Torvalds však nebyl spokojen s jeho přístupem:

Podle mně je problém v tom, že jsi dal všechny soubory do jednoho adresáře. Vložení tečky před jméno souboru neřeší škálovatelnost, jen sníží část problémů se škálovatelnosti v programech. Takže po vytvoření špatného designu přidáš jiné komplikované berličky [cruft] jako kurzor a tečkovou notaci. To samo o sobě není špatný nápad, ale při lepším navržení adresářové struktury bys je nepotřeboval. Bylo by to tak snazší, kdyby se vlákna zobrazovaly jako podadresáře /proc/<tgid>/<tid>/xxx. Více škalovatelné, čitelnější a obecně čistší.

Následovala debata nad správným řešením, ale vývojáři se nebyli schopni dohodnout.

Někteří uživatelé jsou nespokojeni s kódem psaným pod NDA, 23 e-mailů

James Buchanan si stěžoval:

Jsem zvědav, zda i jiní lidé myslí stejným způsobem. Uvažuju o přechodu na BSD kvůli následujícím věcem.

Linux začíná obsahovat kód napsaný pod NDA (smlouva o nezveřejňování) a podobnými šerednostmi, což pro mně zabíjí kouzlo Linuxu. Nikomu to sice nebrání číst si kód, ale tady jde o princip. Ano, je zde spousta hezkých vylepšení a pouze binární ovladače nemohou používat ksysms, jak jsem někde četl. Ale NDA? No tak, kam to povede?

Jeff Garzik poznamenal, že tato situace existuje již celé věky a že i FreeBSD obsahuje ovladače psané pod NDA, neboť takto funguje svět hardwaru. Pokud nepodepíšete NDA, nezískáte podporu Open Source. I Tomas Szepe napsal, že FreeBSD musí podepsat NDA, ale James oponoval, že Theo De Raadt je odmítá podepsat. Jeff odpověděl, že OpenBSD obsahuje ovladače zjevně psané pod NDA, stejně jako ostatní volné BSD. Theo je nejspíše převzal z FreeBSD.

Rik van Riel dodal, že James má samozřejmě právo poskládat si počítač z komponent, pro které existují ovladače nepsané pod NDA. James jinde napsal, že nepoužívá žádné ovladače psané pod NDA, jenže Rik i Tomas odpověděli, že je nemožné najít IDE či moderní SCSI ovladače splňující tuto podmínku. Jeff požádal Jamese o zaslání seznamu ovladačů, které používá a on mu napíše, které jejich části byly napsány pod NDA.

Petice za svobodné ovladače, 1 e-mail

Harry Lepper doporučil podepsat petici za svobodné ovladače na adrese www.petitiononline.com/zxcv7nm.

Související články

Jaderné noviny 206
Jaderné noviny 205
Jaderné noviny 204

Odkazy a zdroje

Kernel Traffic

       

Komentáře