Jaderné noviny - 3/2008

5. 2. 2008 | Jirka Bourek | Jaderné noviny | 4170×

Zrychlení fsck pomocí metaclusterování. Citát: Implementováno od základů. Další náhledy na oops. Citát: S velkou tryskou poletí všechno. 2.6.24-rc8, "závěrečná prověrka". Citát: Velikonoční zajíček. Btrfs - změna velikosti za běhu, konverze z ext3 a další. Citát: Integrita dat. C sémantika, konstanty a ukazatele. Citát: Naštěstí neprogramuješ. LatencyTop, odhalování zpoždění v systému. Citát: Nejlepší patche jsou malé a nevýznamné. Sledování kandidátů na začlenění. Citát: Jenom to zběžně projít. Změny v architektuře x86 k začlenění do 2.6.25. Citát: Tenhle patch spadl z ošklivého stromu.

Obsah

• Zrychlení fsck pomocí metaclusterování
  • Citát: Implementováno od základů
• Další náhledy na oops
  • Citát: S velkou tryskou poletí všechno
• 2.6.24-rc8, "závěrečná prověrka"
  • Citát: Velikonoční zajíček
• Btrfs - změna velikosti za běhu, konverze z ext3 a další
  • Citát: Integrita dat
• C sémantika, konstanty a ukazatele
  • Citát: Naštěstí neprogramuješ
• LatencyTop, odhalování zpoždění v systému
  • Citát: Nejlepší patche jsou malé a nevýznamné
• Sledování kandidátů na začlenění
  • Citát: Jenom to zběžně projít
• Změny v architektuře x86 k začlenění do 2.6.25
  • Citát: Tenhle patch spadl z ošklivého stromu

Následující obsah je © KernelTrap.

Zrychlení fsck pomocí metaclusterování

14. leden, originál

Díky použití techniky, která se nazývá metaclusterování [metaclustering], zrychlí tento patch významně e2fsck na ext3, prohlásil Abhishek Rai. Toto své tvrzení podložil údaji uvedenými ve starším vlákně: Patch u ext3 snižuje celkový čas fsck. Na téměř plném souborovém systému jsem pozoroval 50 - 65% zkrácení. Po několika optimalizacích fsck je to dokonce 80 %.

Většina kritiky se doteď zabývala hlavně problémy s formátováním, které bránily jednoduchému testování patche. Vyřešeno to bylo v novějších verzích. Objevila se také varování, že patch ovlivňuje velké množství ext3 kódu, a tudíž bude vyžadovat velmi důkladné testování.

Abishek popsal, jak patch dosáhne tak velkého navýšení výkonu: Metaclusterování se týká ukládání nepřímých bloků [indirect blocks] ve shlucích založených na skupinách místo toho, aby tyto bloky byly rozprostřeny společně s datovými bloky. Díky tomu je e2fsck rychlejší, protože může číst a ověřovat nepřímé bloky bez nadbytečného pohybu hlaviček disku. Na druhou stranu, pokud se to udělá bez rozmyslu, může být negativně ovlivněna výkonnost při I/O operacích, takže jsme vložili nějaké optimalizace, aby taková sitace nenastala.

Nárůst výkonu fsck je tedy nakonec znát jenom v případě, kdy by čtení nepřímých bloků bylo úzkým hrdlem, což je vcelku často u středních a velkých disků, na kterých je mnoho dat. Pokud čtení nepřímých bloků úzkým hrdlem není, e2fsck je obvykle vcelku rychlý i tak, takže zlepšování výkonnosti není nutné.

Citát: Implementováno od základů

Takové malé varování: Linux vypadá jako unix, ale implementoval jsem ho od základů a téměř bez literatury o tom, jak se to "má dělat".

Linus Torvalds, zpráva z 12. ledna 1992 na Linux Activists mailing list.

Další náhledy na oops

14. leden, originál

Text níže je hlavně pro nováčky - rozepisuji se v něm podrobněji na téma "jak podle hlášení o chybě najít zdroj chyby," začal Al Viro kompletní rozbor dalšího oops linuxového jádra ve snaze naučit víc lidí, jak se to dělá. Al v návodu zahrnul i patch, který opravuje chybu, která oops způsobila. Poznamenal k tomu:

Takové rozbory by možná stály za to, abychom je dělali více či méně pravidelně, obzvlášť pokud se připojí více lidí. Nejde samozřejmě jenom o dohledávání oopsů jako takové, ale o to, že každý na to má svoje triky a shrnout je dohromady by mohlo mnoha lidem pomoci. Arjanova stránka nám dává hezkou sbírku oopsů, takže zjevně máme kde začít.

 

Citát: S velkou tryskou poletí všechno

Spousta věcí je možná - alespoň v tom smyslu, v jakém NASA může říct "s dost velkou tryskou poletí všechno". Jestli je to k něčemu a vyplatí se to, to už jsou samozřejmě odlišné otázky!

Theodore Ts'o, zpráva z 12. ledna 2008 na Linux Filesystem Development mailing list.

 

2.6.24-rc8, "závěrečná prověrka"

16. leden, originál

Nesnáším vydávání tolika -rc, ale ještě víc nesnáším vydávání jádra, když mám pocit, že ještě není dovařené. Změny od -rc7 jsou přitom větší, než byly změny mezi -rc6 a -rc7 (pravděpodobně částečně proto, že lidé byli mezi -rc6 a -rc7 stále na dovolené, takže nám něco posílali až poté.) Takto Linus Torvalds zahájil vysvětlení, proč vydává ještě jeden release candidate místo konečného jádra 2.6.24.

Zkrátka, změny nejsou ve skutečnosti nijak velké a zkrácený log je vcelku nudný, takže jsem si docela jistý, že tohle je poslední -rc a konečné 2.6.24 bude pravděpodobně vydáno někdy příští víkend nebo tak. Mezitím to ještě otestujme a podívejme se, jestli dokážeme opravit nějaké poslední regrese.

Linus pokračoval shrnutím změn: Ovladače, síťování, nějaké aktualizace architektur a ACPI. Slušné množství opravdu malých začlenění. Upřímně nemůžu říct nic víc, než je v přiloženém logu - kromě "spousta malých nudných oprav" v tom není žádný spojující motiv. Tak to má být.

 

Citát: Velikonoční zajíček

Myslím si, že nic z toho, o čem v tomto vlákně diskutujeme, se do 2.6.24 nechystá (pokud Linus nechce, aby jádro 2.6.24 přinesl velikonoční zajíček.)

Adrian Bunk, zpráva ze 14. ledna 2008 na Linux Kernel mailing list

 

Btrfs - změna velikosti za běhu, konverze z ext3 a další

17. leden, originál

Chris Mason oznámil verzi 0.10 svého nového souborového systému Btrfs, která obsahuje následující nové vlastnosti: explicitní zpětné odkazy [explicit back references], změna velikosti za běhu (včetně zmenšení), konverze z ext3 na btrfs na místě, podpora pro data=ordered, volby pro mount, které zakazují kopírování při zápisu [copy-on-write] a počítání kontrolních součtů, a podporu pro hranice [barrier] pro sata a IDE disky.

Formát disku se změnil, takže verze 0.10 není kompatibilní s verzí 0.9. Co se týče podpory pro zpětné odkazy, Chris napsal: Jádrem tohoto vydání jsou explicitní zpětné odkazy pro všechny bloky metadat, datové oblasti a položky v adresáři. Ty budou kritickým stavebním prvkem pro budoucí vlastnosti jako je fsck za běhu a migrace mezi zařízeními. Zpětné odkazy jsou ověřovány během mazání, zpětné odkazy na rozsahy jsou kontrolovány existujícím offline fsck.

Nakonec Chris uvedl několik detailů o utilitě pro konverzi z Ext3 na Btrfs: Konverzní program používá přirozenou vlastnost Btrfs - kopírování při zápisu - aby zachoval původní Ext3 souborový systém, přičemž sdílí datové bloky mezi Btrfs a Ext3 metadaty. Btrfs metadata se vytváří ve volném místě Ext3 a tuto změnu je možné provést natrvalo (místo, které využíval Ext3, je uvolněno) nebo se vrátit k původnímu Ext3.

 

Citát: Integrita dat

Když jde o integritu dat, nemůžete hrát v kostky.

Rik van Riel, zpráva z 9. ledna 2008 na Linux Kernel mailing list

 

C sémantika, konstanty a ukazatele

17. leden, originál

"Const" nikdy neznamenalo nic o tom, že se ta věc nebude měnit. Na tuhle pitomost zapomeňte. C nic takového nemá, začal Linus Torvalds odpověď na dotaz, proč je parametrem kfree() const ukazatel, "const" se týká typu ukazatele a slouží k tomu, aby se chybná užití zviditelnila během překladu. Nemá žádný další význam a kdokoliv si to myslí, toho čekají problémy.

K tomu nabídl dvě vysvětlení a začal velmi jednoduchou C sémantikou: Z velmi zjevné a velmi skutečné perspektivy volajícího, free() skutečně nemění tu věc, na kterou ukazatel ukazuje. Dělá něco úplně jiného - zneplatní ukazatel jako takový. K tomu přidal druhý důvod: Všechno, co může brát jako parametr const ukazatel, by to mělo vždycky udělat. Proč? Protože chceme, aby typy byly tak těsné, jak je to jen možné, a běžný kód by měl potřebovat tak málo přetypování, jak je to jen možné. Když někdo poukázal na to, že GCC 4.2 vypisuje varování, když přetypovává const ukazatel na non-const, Linus odpověděl:

Buď nepoužívejte vadný překladač (přetypování const ukazatele na non-const rozhodně není chyba) nebo přetypujte na "unsigned long" (pokud si překladač i tak bude stěžovat, pak není jenom blbý, ale je vadný). Celý důvod správy paměti je v tom, že my víme, jak ukazatele fungují a chápeme, že mají bitovou reprezentaci, nejenom C sémantiku.

 

Citát: Naštěstí neprogramuješ

Jsem moc rád, že nemáš na práci nic jiného, než dělat trolla v diskuzích. Kdybys opravdu něco naprogramoval, měl bych strach, že se to dostane do něčeho, co lidé používají.

Alan Cox, zpráva ze 16. ledna 2008 na Linux Kernel mailing list

 

LatencyTop, odhalování zpoždění v systému

18. leden, originál

Pomalé servery, vynechávající zvuk, trhané video - všichni známe symptomy zpoždění (latence). Nicméně vědět, co se v systému skutečně děje, co latenci způsobuje a jak to opravit, to jsou složité otázky, na které momentálně není odpověď, píše Arjan van de Van v oznámení o vydání LatencyTopu, nástroje pro vývojáře, který zobrazuje systémová zpoždění, verze 0.1.

LatencyTOP je linuxový nástroj pro vývojáře softwaru (jak kernelu, tak userspace) zaměřený na identifikaci toho, kde se v systému objevují latence a který druh operace/akce způsobuje, že se latence objeví. Když je toto identifikováno, vývojáři mohou kód změnit tak, aby se nejhorším latencím vyhnuli.

Je mnoho typů a příčin latencí, LatencyTOP se specializuje na ty, které způsobují vynechávání zvuku a zadrhávání desktopů. Přesněji řečeno, zaměřuje se na případy, kdy program chce běžet a vykonávat užitečný kód, ale nějaký zdroj není k dispozici (a jádro proces zablokuje). Sledování probíhá jak na úrovni systému, tak na úrovni procesů, takže můžete vidět, co se v systému děje a který proces trpí zpožděním a/nebo ho způsobuje.

 

Citát: Nejlepší patche jsou malé a nevýznamné

Slovní spojení "příliš malý" a "příliš nevýznamný" v mém slovníku vlastností patchů neexistují - z definice nejlepší patche jsou velmi malé a velmi nevýznamné (protože se nakonec zjistí, že o 1000 kroků dál dělají něco hustýho ;-). 99 % našich problémů vychází z patchů "příliš velkých" a "příliš viditelných".

Ingo Molnár, zpráva z 18. ledna 2008 na Linux Kernel mailing list

 

Sledování kandidátů na začlenění

21. leden, originál

Jasně, já vím... další strom, to je to, co všichni chceme, zavtipkoval James Bottomley, když ohlašoval svůj nový strom kandidáti na začlenění [merge candidate], -mc.

Tento strom má specifický účel. Je to můj strom, který sleduje gitové a quiltové stromy všech ostatních, takže se mi dostane včasné varování, když by mělo dojít k nějakým problémům se začleňováním. Pak mě ale napadlo, že by mohl být užitečný také každému, kdo chce podrobněji sledovat, co se děje v upstreamu.

James dodal, že jeho strom je k dispozici v gitu a každou noc se automaticky překládá. Jak můžete vidět z odpatchování [revert] a přeskočení [skip], i teď máme problémy (a to je poté, co jsem opravil většinu z toho, co dělalo problémy u SCSI). Stromy ACPI a x86 odporně kolidují, takže jsem x86 vykopl. Jensův blokový strom obsahuje dva patche, které kolidují s Bartovým ide quiltem. Greg má ve svém stromu jeden patch, který koliduje s jedním z mých.

Tento strom se v součastnosti značně zaměřuje na ukládání dat (tj. například jsem nezačlenil síťové stromy a quilty, protože očekávám, že pravděpodobně nekolidují s mými SCSI stromy). Nicméně, pokud by se to více lidem hodilo, můžu zařadit i další.

 

Citát: Jenom to zběžně projít

Je až moc jednoduché něco jen tak zběžně prohlédnout, říct "vypadá to dobře" a pokračovat něčím dalším, že ano? Byl jsem zděšen, když jsem viděl seznam souhlasů (včetně mého) u commitu, který obsahoval problém s helper_unlock a který jsme právě opravili. Je vpravdě děsivé, že nikdo z nás se na to nepodíval dost zblízka, aby si toho všiml včas.

Nigel Cunningham, zpráva ze 17. ledna 2008 na Linux Kernel mailing list

 

Změny v architektuře x86 k začlenění do 2.6.25

22. leden, originál

Dokončení 2.6.24 se nyní očekává každým dnem, takže správci různých subsystémů začli připravovat shrnutí změn, u kterých se očekává, že budou začleněny do hlavní řady jádra během začleňovacího okna 2.6.25. Ingo Molnár mluvil o změnách pro architekturu x86: V x86.git je právě 763 commitů od více než 90 přispěvatelů, takže by v tomto mailu bylo obtížné všechny zmínit a poděkovat každému.

Společně s douhým seznamem dalších změn jmenoval: pokračující a intenzivní sjednocování arch/x86 a začištovací práce spousty lidí, FIFO frontu pro spinlocky pro zlepšení škálovatelnosti; "regset" generalizace - nejdůležitější krok směrem k podpoře utrace (== ptrace nové generace); podpora pro více než 255 CPU (až 4096, teoreticky až 65535); téměř kompletní podpora pro 64bitový paravirtualizovaný systém; podpora KGDB na x86, konečně!

 

Citát: Tenhle patch spadl z ošklivého stromu

Skláním se před tebou. Myslel jsem, že jsem udělal některé poněkud hrůzostrašné věci se zabudovanými funkcemi gcc a makry, ale od nynějška předávám svou korunu tobě. Jak by řekla moje dcera: tenhle patch spadl z ošklivého stromu a cestou dolů zasáhl každou větev. Velice impozantní.

Linus Torvalds, zpráva z 21. ledna 2008 na Linux Kernel mailing list

       

Komentáře

[Milan Lajtoš]

Typo:

...než dělat trolla v disuzích...

K teme:
Inac Intel to s Linuxom na desktopoch mysli nejako vazne.. Najskor PowerTop, teraz LatencyTop.. Nedavno otvorili dokumentaciu ku svojim grafickym pre kazdeho (nielen pre kernel hackerov), ktovie co bude nasledovat.. Ale myslim, ze ak Linux naozaj prerazi na desktopoch, tak velka vdaka musi ist prave Intelu..

[Robert Krátký]

Typo:

Dík, opraveno.

[David Jaša]

Bude mít $SUBJ nějaký viditelný vliv mimo jádro nebo "jenom" zjednoduší údržbu a vývoj těchto architektur?

[Kvakor]

Pokud si neprekladate jadro sami, tak ne. Pokud ano, tak puvodni adresare v arch jsou nyni jen ukazately na x86. Jinak jsem si zadnych velkych rozdilu mimo arch nevsiml.

[Miloslav Ponkrác]

Jestli to s těmi const Linus myslí vážně, tak mám pocit, že zešílel. Protože const slouží k označení konstatní věci. Je samozřejmě jasné, že lze dělat nepřehledný kód, který bude const používat asi jako když koza řídí atomovou elektrárnu - pokud chcete, prasárny jdou dělat vždycky, ale const tu bylo pro to, aby udrželo přehled a udržovatelnost. Když vidím v kódu const - beru to jako bych v dokumentaci přečetl "tato věc se nebude měnit". Řada kompilátorů se dokonce srdnatě brání i pokusům o prasení a o změnu, a je to tak naprosto správné - programátor by měl vyjadřovat svoje úmysly čistě.

[trekker.dk]

Jestli to s těmi const Linus myslí vážně, tak mám pocit, že zešílel. Protože const slouží k označení konstatní věci.

Pokud vím, tak specifikace jazyka C tvrdí něco jiného.

[Jirka P]

Specifikace jazyka C tvrdí, že modifikace const-objektu pomocí neconst-ukazatele je nedefinované chování. Takže pokud přetypujete neconst-ukazatel na const, dereferencujete a přiřadíte do toho, tak

• si musíte být jist, že ten ukazatel ve skutečnosti vzniknul přetypováním neconst-ukazatele na const, a
• jste prase, zvláště pokud to děláte samoůčelně nebo const napíšete do rozhraní, a pak ho v implementaci nedodržujete

[Jan Kurik]

Tady bych souhlasil spise s Linusem. Pokud oznacim nejakou promenou jako "const", tak tim zadam prekladac aby mi hlidal ze ji nekde v kodu omylem nebudu chtit menit. Ale rozhodne bych to nebral jako zakaz s tou promenou manipulovat (pretypovani na non-const kdyz to opravdu potrebuju). To by hranicilo s omezovanim osobni svobody programatora a to by takovy prekladac mohl byt vystaven i zalobe za porusovani lidskych prav

[Xerces]

On to asi nikdo nezakazuje. Spíše se tady asi naráží na to, že to není tak "úplně čistě". Zkrátka pokud něco není zakázáno, neznamená to, že to je povoleno a naopak. Chápu postoj programátorských estétů, ale Linusovi jsem ochoten tento drobný přešlap odpustit

[lubos]

Asi sis to pomylils s #define, nebo konstantou definovanou v hedri, ale const, neni konstatni vec.

[Luboš Doležel (Doli)]

Mě na GCC štve, že zaboha nechce povolit přetypování z void* např. na short. Povolí to, pokud nejdřív přetypuju na long. Chápu, že se tak asi snaží zabránit tomu, aby programátoři dělali nepřenosiltený kód, ale překvapilo to - ne všechny důvody pro ztrátové přetypování musí být špatné.

[I]

icc muze byt pro tebe / pro Vas lepsi a predevsim kompiluje rychleji a lze s nim gcc plne nahradit, zkompilovat kernel i vse ostatni.

[Libor Chocholaty]

A nebylo by lepsi napsat do kodu co chcete udelat, misto toho, abyste na to zneuzival pretypovani, ktere nema definovane chovani?

Co treba tohle?

short s;
void *v;

s = (int)v & 0xffff;

[Luboš Doležel (Doli)]

Nevím, co je na přetypování nedefinovaného - chová se jasně. A zrovna ani ten váš kód se nezkompiluje.

Jde o to, že je to buzerace. MSVC to připustí bez řečí, aniž by otravoval na podobných hloupostech.

[Jirka P]

ISO 9899:1999, 6.3.2.3/6:

Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type.

[Jirka P]

Mě se ten kód zkompiluje, a pokud tam dám short, tak to akorát hodí warning. Takže jestli používáte -‍Werror a nezkompiluje se vám to, je to pouze a jenom váš problém.

MMCH MSVC jsem nezkoušel na tenhle kód, ale MSVC 2008 beta mi třeba na přetypování size_t -> unsigned hodí warning (něco ve smyslu "potential 64-bit portability problem...")

[David Watzke]

Mě se ten kód zkompiluje,

No, gcc to vezme, ale g++ ne:

error: cast from 'void*' to 'int' loses precision

[Jirka P]

To bude tím, že ve standartu c++ není nic, co by podobnou věc umožňovalo. Jediná konverze pointer -> integer je reinterpret_cast, a k němu relevantní odstavec ze standartu je 5.2.10/4:

A pointer can be explicitly converted to any integral type large enough to hold it. The mapping function is implementation-defined [Note: it is intended to be unsurprising to those who know the addressing structure of the underlying machine. ]

[Michal Kubeček]

Nevím, co je na přetypování nedefinovaného - chová se jasně.

Určitě? A jak?

[koetchko]

Typo:

LatencyTop, odhalovnání zpoždění v systému

[Milan Vančura]

> Pokud čtení nepřímých bloků úzkým hrdlem není, e2fsck je obvykle vcelku rychlý i tak, takže zlepšování výkonnosti není nutné.

Pokud čtení nepřímých bloků úzkým hrdlem není, je e2fsck obvykle vcelku rychlý i tak a zlepšení výkonnosti se neprojeví.

Puvodni formulace rika neco jineho - ze mame nejaky jiny ukol/cil a k jeho splneni je nebo neni nutne zvyseni vykonnosti. (alespon podle meho nazoru a citeni cestiny). Samozrejme vim, ze jsem puntickar, to mi nemusite psat

[trekker.dk]

Jenže ta druhá formulace říká něco jiného, než se píše v tom anglickém textu (aspoň podle mě)

[ak47]

Jak muze nekdo prelozit "enough thrust" jako velkou trysku ?

Jak by potom vypadal prelozenej sig "With enough thrust, pigs fly ok ..." ? A kam ze tomu nebohemu zvireti tu trysku chcete cpat ? )))

[Michal Kubeček]

Zkuste hádat… :-)

[trekker.dk]

Tomu se říká volný překlad. Rád se nechám poučit, jak bys to TY přeložil přesně - jestliže to nebude znít blbě, klidně to příště použiju.

[happy barney]

prečo "cpát"? ono ju nemá? ... a v tom vašom úryvku by som voľne použil thrust => ťah => usmernený výtok plynov )