Portál AbcLinuxu, 9. května 2025 00:51
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.
Tomas Szepe zaslal patch pro zobrazení kernel panics v morseově kódu a zdůraznil jeho výhody:
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.
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:
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.
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.
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.
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.
Harry Lepper doporučil podepsat petici za svobodné ovladače na adrese www.petitiononline.com/zxcv7nm.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.