Jaderné noviny - 29. 10. 2008

28. 11. 2008 | Jirka Bourek | Jaderné noviny | 2419×

Aktuální verze jádra: 2.6.28-rc2. Citáty týdne: Jim Gettys, Harald Welte, Matt Mackall, Al Viro. Interview videa z Jaderného Summitu. Začleňovací okno 2.6.28 se zavírá. Sledování problémů tbench. Squashfs předložen k začlenění do hlavní řady.

Tento článek je překladem z anglického originálu, a proto vychází se zpožděním.

Obsah

• Aktuální verze jádra: 2.6.28-rc2
• Citáty týdne: Jim Gettys, Harald Welte, Matt Mackall, Al Viro
• Interview videa z Jaderného Summitu
• Začleňovací okno 2.6.28 se zavírá
• Sledování problémů tbench
• Squashfs předložen k začlenění do hlavní řady

Aktuální verze jádra: 2.6.28-rc2

Současné vývojové jádro je 2.6.28-rc2, které Linus vydal 26. října. Přidává pouhých 22 sad měn k 2.6.28-rc1, které vyšlo 23. Toto jádro je známo jako "Zabijácký netopýr zkázy" (Killer Bat of Doom).

Citáty týdne: Jim Gettys, Harald Welte, Matt Mackall, Al Viro

Na linuxové virtuální terminály a jejich komplexitu v jádře se dívám se směsí bázně a ohromení, že tímto směrem mířilo tolik úsilí...

-- Jim Gettys

Ve skutečnosti považuji to, že lidé berou telefony Motorola EZX nebo MAGX (a nyní Android) jako "linuxové", tak trochu za urážku. Protože všechny svobody Linuxu (psaní nativních aplikací proti nativnímu linuxovému API, které linuxoví vývojáři znají a milují, možnost vyvíjet Linux [jádro]) jsou omezeny.

Vzhledem k tomu - k čemu je Linux v těchto zařízeních dobrý? Určitě neznamená žádný prospěch pro uživatele. Znamená prospěch pro výrobce handsetů, kteří mohou vynechat poměrně drahý poplatek za licencování Windows Mobile. Jo a mají k dispozici lepší správu paměti než na Symbianu ;-)

To je konec civilizace [brave new world]. Je mi z toho špatně.

-- Harald Welte

Skutečným problémem je to, že pokud se jádro zvětší o 12k pokaždé, když vývojář řekne "v čem je problém?", bude brzy opravdu hodně velké.

-- Matt Mackall

Takže seděl v hlavní řadě jádra po 4 roky. Během těchto let ho nikdo ani nezkusil zkompilovat. Nicméně byly tu patche, které ho ovlivňovaly - včetně tak vzrušujících záležitostí, jako je odstranění bílých znaků na konci řádků, které celou tu zatracenou věc rozhodně značně vylepšily.

-- Al Viro

Interview videa z Jaderného Summitu

Linux Foundation vytvořila celou hromadu video interview s vývojáři jádra z letošního Jaderného summitu. Jsou k dispozici krátká 5-10 minut trvající interview s 15 různými vývojáři jádra. Můžete se podívat, jak odpovídali Linus Torvalds, Ted Ts'o, Greg Kroah-Hartman a mnoho dalších, včetně šéfredaktora LWN Jonathana Corbeta. Videa jsou k dispozici jak ve formátu ogg, tak ve flashi.

Začleňovací okno 2.6.28 se zavírá

Po předchozím shrnutí bylo začleněno okolo 1000 sad změn. Mnoho z nich přišlo ze stromů specifických pro architektury. Další změny začleněné v tomto období zahrnují:

• Jsou zde nové ovladače pro:

  • síťové adaptéry Mellanox ConnectX 10GbE
  • GPIO řadiče PowerPC PPC40x a PPC44x
  • speciální klávesy "Let's Note" laptopů Panasonic
  • podsvícená [backlight] a LCD zařízení Sharp SL-6000
  • podsvícená zařízení Dialog Semiconductor DA9030/DA9034
  • podsvícená zařízení Tabletkiosk Sahara Touch-iT
  • ATA řadiče Toshiba TX4939 SoC

• Přes strom staging byl začleněn ještě jeden ovladač nepřipravený na premiéru; podporuje cardbus zařízení Redrapids Pocket Change. Strom staging také přinesl rozsáhlou sadu oprav ovladačů, které byly přidány dříve v tomto začleňovacím okně.

• Jádro získalo podporu pro stacky protokolu ultra-wideband. UWB lze použít pro běžné síťování, ale okamžitou aplikací je bezdrátové USB, které bude v 2.6.28 podporováno.

• Kód ACPI dokovací stanice získal podporu pro hotplug události stanice a baterie.

• Architektura IA64 nyní podporuje Xen. Do IA64 byla také přidána podpora pro DMA remapování zařízení (IOMMU)

• Do architektury PowerPC byla přidána podpora pro kdump

• Souborový systém 9P (Plan9) nyní podporuje RDMA.

Změny viditelné pro jaderné vývojáře zahrnují:

• Nové makro core_param():

  core_param(name, var, type, perm);

  Jeho účelem je definovat "vnitřní" [core] parametry a umožnit jejich reprezentaci v /sys/module/kernel/parameters.

• Nyní je možné vytvořit pracovní frontu [workqueue] s prioritou reálného času:

  struct workqueue_struct *create_rt_workqueue(const char *name);

• Bloková vrstva se významně změnila, z většiny operací blokových zařízení byly odstraněny parametry inode a file. Nové API vypadá takto:

  struct block_device_operations {
      int (*open) (struct block_device *bdev, fmode_t mode);
      int (*release) (struct gendisk *gd, fmode_t mode);
      int (*locked_ioctl) (struct block_device *bdev, fmode_t mode, 
                           unsigned cmd, unsigned long arg);
      int (*ioctl) (struct block_device *bdev, fmode_t mode, 
                    unsigned cmd, unsigned long arg);
      int (*compat_ioctl) (struct block_device *bdev, fmode_t mode, 
                           unsigned cmd, unsigned long arg);
      int (*direct_access) (struct block_device *bdev, sector_t sector,
                            void **kaddr, unsigned long *pfn);
      int (*media_changed) (struct gendisk *gd);
      int (*revalidate_disk) (struct gendisk *gd);
      int (*getgeo)(struct block_device *bdev, struct hd_geometry *geo);
      struct module *owner;
      };

  Nové prototypy odstraňují ukazatele na struktury file a inode, které byly předchozími jádry předávány. Všimněte si, že ioctl() metoda se nyní volá bez velkého jaderného zámku; kód, který potřebuje ochranu od BKL, musí místo toho explicitně definovat funkci locked_ioctl().

• Bylo začleněno API časovačů s rozsahem; volající nyní mohou specifikovat časové období, v němž chtějí, aby jim bylo dodáno vypršení limitu. Jádro poté může využít rozsahu k nashromáždění probuzení a udržovat tak procesor v nečinnosti v delších intervalech.

Správce linux-next Stephen Rothwell tentokrát vytvořil seznam patchů linux-next, které se do 2.6.28 nedostaly. Pravděpodobně největší opomenutí je práce na dokladech, u které se zdálo, že je tentokrát na začlenění připravena. Mezi další změny, které se nepodařilo začlenit, patří katalog zpráv (u kterého se zdá, že bude vyžadovat změnu přístupu) a TOMOYO Linux (u kterého se zdá, že uvízl ve staré známé bažině "nový bezpečnostní modul s pravidly založenými na cestách").

Nyní začíná stabilizační období. Linus možná chtěl pro tento vývojový cyklus udat tón, když 2.6.28-rc2 vydal mnohem menší a dříve, než by se obvykle dalo očekávat. Pro srovnání: 2.6.25-rc2 mělo od 2.6.25-rc1 aplikováno 359 patchů. U 2.6.26-rc2 bylo začleněno 446 sad změn a u 2.6.27-rc2 byl součet 780. Naopak do 2.6.28-rc2 se dostalo celkem 22 změn. Linus říká:

A hej, možná dokonce můžeme pokračovat s tím hezkým modelem "po -rc1 pouze malé opravy". Já vím, zní to šíleně, ale je skutečné potěšení vydat -rc2 s pouhou hrstkou oprav skutečných problémů, které lidi vidí. To je nápad!

Pokud tento vzor vydrží, může se dobře stát, že se 2.6.28 stabilizuje rychleji a úspěšněji než jeho předchůdci. V každém případě to bude zajímavé pozorovat.

Sledování problémů tbench

Jaderní vývojáři mají na benchmarky různé pohledy. Benchmarkovací nástroj může efektivně kvantifikovat specifické aspekty výkonnosti systému. Na druhou stranu nejsou benchmarky skutečná zátěž; optimalizace pro benchmark může často systém narušit tak, že to bude újma pro skutečné aplikace. Vzhledem k tomu, že hackeři jádra většinou nepovažují optimalizaci pro benchmarky za jednu svých největších priorit, regresím benchmarků obvykle přiřazují nižší váhu. Někdy ale problém benchmarku indikuje skutečný problém v jádře.

Benchmark tbench má za úkol měřit výkonnost síťování; sestává se ze sady procesů, které rychle vytvářejí malé požadavky a posílají je procesu serveru. Vzhledem k tomu, že jsou požadavky malé, nestráví se moc času přesouváním dat; vše je záležitost přesouvání malých paketů - a plánování mezi procesy. V srpnu Chritoph Lameter ohlásil, že výkonnost tbench v hlavní řadě jádra už nějaký čas klesá. Jeho systém byl schopen přesunout 3208 MB/s s jádrem 2.6.22, ale pouze 2571 MB/s s jádrem 2.6.27-rc. Každé vydání mezi nimi vykázalo pokles od předcházející verze, 2.6.25 vykazovalo pokles obzvláště velký. Ostatní byli schopni tyto výsledky reprodukovat a zapojili se do různých spekulací o tom, kde může být problém, ale zdá se, že se zpočátku nikdo skutečně neponořil do systému, aby zjistil, co se děje.

Na linux.conf.au 2007 měl Andi Kleen přednášku popisující různé typy jaderných hackerů. Jedním z nich byl "ruský matematik", který často je, podle Andiho podezření, ve skutečnosti místnost plná talentovaných vývojářů vystupujících pod jedním jménem. Jevgenij Poljakov tento pohled jenom posílil, když počátkem října vysledoval nejproblémovější commit během procesu, který, jak řekl, zahrnoval "pouhých pár set kompilací." Během tohoto procesu dal dohromady graf výsledků tbench, který, jak řekl, se hodí ke strašení dětí. Díky ohromnému množství práce byl nakonec schopen ukázat prstem na patch v plánovači - tedy v ničem, co by se týkalo síťového stacku.

Jevgenij konkrétně zjistil, že patch přidávající tiky preempce s vysokým rozlišením způsobil problém. Nápad za tímto patchem spočíval v tom, že se časové úseky [time slices] zpřesní naplánováním preempce v přesném čase. Dává to smysl; jakmile byly eliminovány pravidelné tiky hodin, není důvod, proč neprovést preempci v čase, kdy plánovací algoritmus říká, že se má provést. Bohužel se zdá, že tato změna také přidává dostatečnou režii na to, aby významně snížila výsledky tbench; když ji Jevgenij vyřadil, výkonnost u něj stoupla z 373 MB/s na 455 MB/s. To se zdá být vcelku jasným náznakem toho, že v preemptivních ticích s vysokým rozlišením je něco špatně.

V tomto bodě veřejná diskuze utichla, i když se zdá, že mnoho vývojářů na problému pracovalo mimo konferenci. David Miller nakonec vysledoval největší potíže v probouzecím kódu, přičemž dal najevo, že nebyl nadšený z toho, že to musel dělat. Nakonec byl začleněn patch (do 2.6.28-rc2), který preemptivní tiky s vysokým rozlišením zakazuje. Vzhledem k tomu, že šlo o soukomou diskuzi, není příliš jasné, proč tato změna trvala tak dlouho. Je ale několik pravděpodobných důvodů. Jedním z nich je to, že je tato konkrétní vlastnost ve výchozím nastavení zakázaná, takže většina uživatelů na problém s výkonností, který vytváří, nenarazila.

Je zde ale otázka porovnání výsledků benchmarku proti důsledkům pro další, "skutečnou" zátěž. Ingo Molnár řekl:

Je to ale složité rozhodnutí bez jasného řešení. Na jedné straně máme lidi, kteří do horké cesty přepínání kontextu přidávají víc a víc věcí s (převážně platným) tvrzením, že plánovač je v porovnání s většinou ostatních věcí studená cesta. Na druhou stranu tu máme lidi, kteří dělají benchmarky s velkým poměrem přepínání kontextu a stěžují si na režii pokaždé, když je přidáno něco, co vylepšuje kvalitu plánování zátěže, která nepřepíná kontext tak masivně jako tbench. Rovnováha je tady složitá a oba tábory uspokojit nejde.

Podle jeho pohledu je potřeba porovnat výkonnost benchmarku intenzivně využívajícího plánovač proti širší hodnotě dalšího vylepšení plánovače. David Miller má nicméně o situaci jiné mínění:

Jestli si teď myslíme, že je v pořádku, aby bylo dražší vybrat, která úloha poběží, než poslat 64 bytů přes TCP socket a potom blokovat při čtení, rád bych přestal Linux používat :-). To je "skutečná práce" a jestliže bude plánovač dražší než "skutečná práce", prohráváme.

Podle Davidova pohledu se výkonnost plánovače neustále zhoršuje od doby, kdy se ve 2.6.23 přešlo na zcela férový plánovač [Completely Fair Scheduler]. Byl by rád, kdyby se věnovalo nějaké úsilí na obnovení části výkonu před-CFS plánovače; konkrétně si myslí, že by Ingo a spol. měli pracovat na opravě (dle jeho mínění) regresí, které způsobili.

V současnosti byla nejhorší regrese výkonnosti "opravena" zakázáním vlastnosti preemptivních tiků s vysokým rozlišením; Ingo říká, že se nevrátí, dokud nebude možné ji podporovat bez zpomalení věcí. Nicméně se zdá, že plánovač se zpomalil také v mnoha dalších ohledech. Autor článku si zde dovolí předvídat: nyní, když bylo na problém ukázáno takto jasně, si někdo najde čas a opraví problémy do bodu, kdy bude CFS rychlejší než O(1) plánovač, který ho předcházel.

Kromě toho jsou zde námitky, že by plánovač neměl přijímat vinu za všechny pozorované regrese ve výsledcích tbench. Vývojáři se tedy budou muset podívat na zbytek systému, aby zjistili, co se v něm děje. Dobrá zpráva je, že to je zjevná výzva s objektivním způsobem, jak měřit úspěšnost. Jakmile problém dosáhne této úrovně srozumitelnosti, jedná se dále většinou o prostou záležitost nějakého programování.

Squashfs předložen k začlenění do hlavní řady

Komprimovaný souborový systém squashfs se používá ve všem od Live CD po embedded zařízení. Mnoho nebo většina distributorů ho v takových situacích dodává, ale i přesto byl léta spravován mimo hlavní řadu jádra. Zdá se, že se to mění, protože Phillip Lougher jej nedávno předložil k začlenění do hlavní řady. Reakce byla obecně příznivá, Andrew Morton žádal, aby ho Phillip předal dál: Prosím, připrav strom pro začlenění do linux-next a pokud se neukáží vážné problémy, navrhnu začlenění do 2.6.29. Zdá se tedy, že je správný čas podívat se na některé vlastnosti a schopnosti Squashfs.

Základním nápadem Squashfs je generovat komprimovaný obraz souborového systému nebo adresářové hierarchie, kterou lze připojit jako souborový systém pouze pro čtení. To lze udělat za účelem archivace sady adresářů nebo jejich uložení na zařízení s menší kapacitou, než která by jinak byla potřeba. To druhé se používá jak u Live CD, tak u embedded zařízení, aby se více vešlo do méně.

Jsou to téměř čtyři roky, co byl Squashfs naposledy předložen v linux-kernel. Od té doby byl téměř zcela přepsán podle komentářů z tohoto pokusu. Navíc prošel dvěma revizemi rozvržení souborového systému se snahou umožnit 64bitové velikosti souborů a souborových systémů. Další významnou změnou je, že nyní je Squashfs little-endian, takže ho lze číst na jakékoliv architektuře bez ohledu na endianitu.

K vytvoření obrazu slouží utilita mksquashfs, obraz lze poté připojit přes loopback (ze souboru) nebo z obyčejného blokového zařízení. Jedna z vlastností, která byla přidána po původních pokusech dostat ho do hlavní řady - v reakci na stížnosti, které se objevily - je možnost exportovat souborový systém Squashfs přes NFS.

Squashfs používá pro kompresi dat a metadat souborového systému gzip a dosahuje velikostí přibližně jedné třetiny souborového systému ext3 se stejnými daty. Výkonnost je také poměrně dobrá, i když se porovnává s mnohem jednodušším cramfs - komprimovaným souborovým systémem pouze pro čtení, který je již v jádře k dispozici. Podle Phillipa byla tato čísla shromážděna před mnoha lety se staršími verzemi kódu; novější hodnoty by měly být ještě lepší.

Dříve někteří vývojáři odporovali přidání dalšího komprimovaného souborového systému do jádra, takže Phillip zdůrazňuje několik důvodů, proč je Squashfs lepší než cramfs. Podpora pro větší soubory a souborové systémy je určitě přesvědčivá, ale fakt, že cramfs osiřel a není spravován, bude také pravděpodobně hrát roli. Squashfs navíc podporuje mnohem více vlastností "běžných" linuxových souborových systémů, jako jsou reálná čísla inodů, hardlinky a exportovatelnost.

Andrew v e-mailu odkazovaném výše sepsal seznam návrhů, jak Squashfs vylepšit, ale dokumentace je rozhodně jedna z oblastí, která je poněkud pozadu. Squashfs konkrétně spravuje svou vlastní cache, což Andrewa zmátlo:

Proč tyto bloky prostě nedekomprimovat do cache stránek a nenechat VFS řešit cachování?

Skutečnou chybou je zde to, že tato v podstatě zjevná otázka nebyla zodpovězena nikde v návrhu patche (pokud si vzpomínám). Jak to opravit?

Myslím si, že potřebujeme squashfs.txt, který bude takové věci vysvětlovat.

Jedním z důvodů, proč squashfs nepoužívá cache stránek, je, že umožňuje mít několik velikostí bloků od 4k po 1M s výchozí hodnotou 128k. Lepších poměrů komprese lze dosáhnout s větší velikostí bloků, ale to s cache stránek nefunguje dobře, jak poznamenává Jörn Engel: Jeden z problémů, zdá se, spočívá v tom, že tvoje velikost bloků může přesáhnout velikost stránky a zatím skutečně není žádná infrastruktura, která by takové případy řešila.

Phillip kód přesunul do gitového repozitáře, pravděpodobně proto, aby byl připraven na zařazení do linux-next. Poznamenal, že CE Linux Forum během posledních čtyř měsíců finančně velmi pomohlo, což mu umožnilo pracovat na tom, aby se Squashfs dostal do jádra. S dalším testováním, které vzejde ze začlenění do linux-next, se zdá docela možné, že bychom Squashfs mohli vidět v 2.6.29.

       

Komentáře

[GandY]

oprava:

Přidává pouhých 22 sad změn k 2.6.28-rc1, ...

[Filip Jirsák]

hackeři jádra většinou nepovažují optimalizaci pro benchmarky za jednu ze svých největších priorit

V článku to "ze" chybí.

sestává se ze sady procesů

Podle mne se nepoužívá vazba "sestávat se z" ale "sestávat z".

[petr_p]

Podle mne se nepoužívá vazba "sestávat se z" ale "sestávat z".

Já jsem opačného názoru. Vynechání zvratného zájmena jsem poprvé slyšel z novodobých médií a velmi mě tahá za uši.

[Filip Jirsák]

Při hledání ve veřejné části ČNK jsem mezi 34 výskyty slova „sestávat“ nenašel ani jedno použití spolu se zvratným zájmenem, při hledání „sestává“ je mezi prvními padesáti výsledky jediný, kde je zvratné zájmeno použito.

[petr_p]

Taky jsem tam hledal a „sestává se“ 3 výsledky, „se sestává“ 17 výsledků. Uznávám, že zvratná forma není tak rozšířená (dokonce někteří písmáci tvrdí, že zvratná forma je chybná, prý se jedná o smíšení vazby se slovesem skládat se).

Připomíná mi to vazbu „obchodovat (s) čím“, kde jsou přípustné obě podoby.