AbcLinuxu:/ Články / Jaderné noviny 234

Štítky: boot, hardware, Intel, Internet, kernel, NFS, ovladače, patch, programování, RAM, rsync, sítě, software, souborové systémy, textové editory, USB, Vim

Jaderné noviny 234

17. 10. 2003 | Robert Krátký | Jaderné noviny | 3436×

Stav podpory velké paměti. BitMover žádá vývojáře kernelu, aby si přestali stěžovat na BitKeeper. Menší změny v netpoll a netconsole. Kód od Intelu pro hlášení o událostech kernelu. Řešení problémů s tabulkami diskových oddílů.

Do konference přišlo celkem 1785 emailů, nejvíce jich poslali Greg KH, Alan Cox, Chris Wright.

Stav podpory velké paměti, 48 e-mailů

Stephan von Krawczyn oznámil, že když na 2.4.22 upgradoval ze 4 giga RAM na 6, všichni jeho NFS klienti začali odpadávat, všeobecná interaktivita se zdála děsná a výkon sítě také poklesl. Zeptal se, jestli to tak prostě bývá a Andrea Arcangeli navrhl zkusit kernel 2.4.22-aa1. Neil Brown problémy také nedokázal vysvětlit, ale navrhl upgradovat na některý z 2.6-test kernelů nebo alespoň nakonfigurovat kernel na využití maximálně 4 giga místo 64, jak to Stephan udělal původně. Neil uznal, že by to nevyužilo všechnu Stephanovu paměť, ale bylo by zajímavé vidět, jestli se systém opět zrychlí. Stephan řekl, že už to zkusil a zjistil, že systém fungoval perfektně, ačkoliv ponechával 2 giga RAM nevyužitých.

Marcelo Tosatti také navrhl vyzkoušet Andreovy patche, protože obsahují výrazné změny v subsystému virtuální paměti. Stephan to zkusil se 4 giga RAM a opět nenarazil na problém, i když problémy se 6 giga zůstávaly.

Někdy v tuto dobu poznamel Alan Cox: 2.6 Strom je v tomhle trochu lepší, ale konec konců, nezvládne-li to tvůj I/O subsustém, tak ten stroj nebude mít ideální výkon. Pro některé zátěže je velkou výhrou mít extra RAM, pro jiné je I/O skutečný problém. Také by v některých případech bylo zajímavé vyzkoušet použít tu další RAM nad hranicí 4G jako obrovský ram disk a využít jej coby první swapovací zařízení. Nevím však o nikom, kdo by to zkoušel.

BitMover žádá vývojáře kernelu, aby si přestali stěžovat na BitKeeper, 75 e-mailů

Během diskuze poslal zprávu Andrea Arcangeli a jeho podpis obsahoval následující text:

/*

 * Pokud pro zásadní oblasti svého podnikání odmítáte závislost

 * na uzavřeném software, mohou se vám hodit tyto odkazy:

 *

 * rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.5/

 * rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.4/

 * http://www.cobite.com/cvsps/

 *

 * svn://svn.kernel.org/linux-2.6/trunk

 * svn://svn.kernel.org/linux-2.4/trunk

 */

Larry McVoy odpověděl:

Poskytujeme službu, která umožňuje všechny tyhle věci, a bez naší dobré vůlu je tato služba ohrožena. Ty se veřejně navážíš do poskytovatelů této služby.

Chceš-li to dělat, fajn, ale to nás vede k otázce:

Nezněla dohoda tak, že my uděláme bránu a vy přestanete fňukat?
Proč bychom tu službu měli poskytovat, když pořád fňukáte?
Proč vás nezamkout za firewall, když fňukáte?
A nebo, jestli firewall nebude stačit, pozdržet bránu o den nebo dva?

Pavel Machek odpověděl: Eh? Vy poskytujete službu, on poskytuje reklamu. Nevidím v tom žádné navážení. Řekl bych, že Andrea o vývoji kernelu neuvažuje jako o podnikání, takže to ani není mířeno na vás. Ale tak jako tak, je to *jeho* podpis.

A Larry řekl:

Ostatní by s tvým pohledem nemuseli souhlasit. Většina lidí si ten podpis přečetla a viděli v něm negativní komentář o BitKeeperu.

Lidé mi říkají, že mají za to, že pokud BitMover nemá žádný prospěch z volného používání BK, volný BK se zruší. Lidé nechtějí záviset na mé dobré vůli. Chtějí, aby měl BitMover prospěch, takže na mojí dobré vůli nebude záviset. Dávat BK je jen chytrý obchod.

Pokud je tohle opravdu to, co si tady lidé myslí, pak to znamená, že pro BitMover musí být nějaký prospěch. Takový prospěch je i to, že můžeme říkat, že tým kernelu ho používá a získat tak nějaké marketingové výhody. Prospěch se však snižuje negativními poznámkami.

Vzhledem k tomu, kolik práce a nepříjemností je s poskytováním BK, dává smysl, že se lidi necítí dobře když jsou na tom závislí. Nechápu, že jsem si to neuvědomil dříve. Je to nestabilní situace.

Vím, že existují lidé, kteří nebudou nikdy šťastni, dokud nebude vše pod GPL. Nemůžu těm lidem pomoci jinak, než jim poskytnout bránu. Na oplátku musí tito lidé přestat fňukat, brána musí stačit.

K těm ostatním se obracím pro návrhy, jak zařídit, aby byla situace stabilnější. Chilku mi to trvalo, ale už chápu, proč jste nervózní. Já bych byl na vašem místě taky. Já jsem nervózní z nějakého opravdového marketingového využití faktu, že kernel používá BK, protože by to jen vedlo k dalšímu napadání. Začínám si myslet, že kdybychom to dělali, možná by to vlastně znamenalo méně napadání, protože pak bychom my potřebovali, abyste i nadále měli BK zdarma. Máte-li na to názor, rád bych ho slyšel.

Nikdo neodpověděl.

Menší změny v netpoll a netconsole, 10 e-mailů

Chris Wright nabídl krátký patch a vysvětlil: Pár malých úprav. První je v netpoll_setup. Pro moji e100 byl usazovací čas příliš krátký a systém zamrzl. Druhý je pro netconsole, aby zaregistrovala konzoli s CON_PRINTBUFFER. Pomáhá to s debugováním problémů brzy při bootu, když chcete zachytit data před inicializací netconsole. Možná by z toho měl být parametr pro netconsole

Matt Mackall navrhl, aby byla úprava času usazení netpoll_setup konfigurovatelná na příkazové řádce místo napevno v kódu. Chris s tím souhlasil. Matt také řekl, že u té změny pro netconsole nevadí, když nebude podmínečná.

Kód od Intelu pro hlášení o událostech kernelu, 17 e-mailů

Juan Villacis z Intel napsal:

Požadujeme zařazení následujícího patche pro dodatečné hlášení o událostech kernelu [kernel event notification] do nadcházejího 2.6.x kernelu.

Současné profilovací háčky [profiling hooks] poskytují hlášení na konci života úlohy (tj. task exit, mmap exit a exec unmap). Rádi bychom měli další hlášení na počátku úlohu (tj. fork, execve, kernel image loads, a user image loads).

Máme za to, že profilovací nástroje jako Oprofile, Perfmon a VTune by z dodatečných háčků měly prospěch, protože by se zlepšila přesnost a kompletnost výkonových údajů, obzvláště při práci v prostředí, které může dynamicky vytvářet a rušit spustitelný kód (jako Java). Kromě toho by tyto háčky mohly být využívány k měření různých druhů výkonových údajů (např. "forks za vteřinu"), které teď nejsou jiným způsobem dostupné.

Náš patch dodržuje konvence používané stávajícími profilovacími háčky a je relativně malý.

Ocenili bychom váš názor/komentáře k našemu návrhu.

Jesse Barnes patch podpořil: Já bych to uvítal, protože nástroje moniturující výkon by pak nemusely patchovat syscall tabulku.

Ale Andrew Morton řekl, že přijetí do kernelu by záleželo na licenčních záležitostech. Napsal: Pokud kód, který ty háčky potřebuje, není ve stromu na kernel.org, mohou si lidi ten patch aplikovat na hlavní kernel zároveň s patchem pro analýzu výkonu. Není-li kód, který tyto háčky potřebuje, licencován odpovídajícím způsobem, představovaly by ty háčky vlastně obejití GPL, což není směr, kterým se chceme vydat.

Juan odpověděl:

Náš testovací jaderný modul využívající tyto háčky je GPL a mohl by být zařazen do stromu kernel.org.

Současná verze ovladače (také GPL, ale s háčky sys_call_table pro 2.4.x kernely) je na

http://www.intel.com/software/products/opensource/vdk/

Počátkem příštího týdne plánujeme dát na tu samou stránku nový ovladač pro kernel 2.6.0-test5 (s aplikovaným patchem pro hlášení událostí) a jak IA-32, tak IA-64.

Jun Nakajima byl toho názoru, že Intel se nesnaží obejít GPL, ale pouze implementuje funkce, které jsou svým rozsahem podobné jinému kódu v kernelu.

Andrew byl spokojený a zeptal se spolu s dalšími lidmi na některé věci ohledně kódu, které Juan trpělivě vysvětlil.

Řešení problémů s tabulkami diskových oddílů, 14 e-mailů

Andries Brouwer napsal:

Jak všichni ví, není dobrý nápad nechávat kernel hádat, jestli na daném zařízení je tabulka oddílů a pokud ano, jakého typu. Přesto to však dělá téměř každý.

Až doposud se to řídilo pravidlem: diskety tabulku oddílů nemají, disky ji mají a u ZIP jednotek to nikdo neví. S USB máme další druhy blokových zařízení, které mohou, ale nemusejí mít tabulku oddílů (a pokud žádnou nemají, většinou tam bývá FAT filesystém s bootsektorem). V takových případech kernel očekává tabulku oddílů a pokud tam žádná není, je z toho zmatek. Je potřeba nějaká heuristika.

Je možné to zjišťovat různě (pro tabulku oddílů DOSového typu: boot ukazatel musí být 0 nebo 0x80, oddíly nejsou větší než disk, nerozšířené oddíly jsou navzájem nesouvislé; pro boot sektor: začíná skokem, počet bytů na sektor je 512 nebo alespoň mocnina dvou, počet sektorů na cluster je 1 nebo alespoň mocnina dvou, počer rezervovaných sektorů je 1 nebo 32, počet kopií FAT je 2, ...).

Zkoušel jsem minimální test a je dostatečný pro boot sektory a DOSové tabulky oddílů, které tu mám.

Takže: jsou mezi vámi lidé s tabulkami oddílů DOSového typu nebo FAT filesystémovými bootsektory, kterým připojený test dává chybnou odpověď? Rád bych získal kopii takových sektorů.

Předpokládám, že navrhnu nějaký test správnosti parsování tabulky oddílů DOSového typu a doufám, že pak ve většině případů rozpoznám přítomnost celodiskového FAT filesystému.

Linus Torvalds reagoval na Andriesův první odstavec:

To říkáš teď a říkal jsi to už dlouho dobu. Ale tvrdit, že to "všichni ví", to prostě není pravda.

Především si myslím, že kernel, který nerozděluje na oddíly, je od základu špatný. Jsem si jistý, že i jiní by souhlasili.

Máš-li neobvyklé případy (a přiznejme si, těch moc není - tradičně jsme měli _velmi_ málo problémů s dělením na oddíly), měl by být schopen je zvládnout z uživatelského prostoru a uživatelský prostor by měl být schopen říct kernelu o speciálních oddílech.

A víš co, překvapení, překvapení, přesně to lze provést.

A taky, překvapení, překvapení, skoro nikdo to nedělá. Protože výchozí nastavení je tak rozumné.

Opakuj po mně: udělej výchozí nastavení tak rozumné, aby o něm většina lidí ani nemusela přemýšlet.

Zkrátka si myslím, tvá první věta (na které visí zbytek tvého argumentování) je od _základu_ chybná.

Andries protestoval, diskutoval ještě s různými lidmi, až se konečně Linus znovu na jeho patch podíval, namítl několik věcí ohledně implementace a pak se debata pravděpodobně přesunula na soukromé maily.

V originálu Kernel Traffic 234 vyšla navíc ještě tato témata:

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licencí GPL verze 2.