Jaderné noviny – 12. 5. 2011: Dohady kolem rozbití powertopu

23. 5. 2011 | Jirka Bourek | Jaderné noviny | 4345×

Aktuální verze jádra: 2.6.39-rc7. Citáty týdne: Greg Kroah-Hartman, Andrew Morton. Stabilní stránky. Ftrace, perf a ABI pro sledování.

Obsah

• Aktuální verze jádra: 2.6.39-rc7
• Citáty týdne: Greg Kroah-Hartman, Andrew Morton
• Stabilní stránky
• Ftrace, perf a ABI pro sledování

Aktuální verze jádra: 2.6.39-rc7

Současné vývojové jádro je 2.6.39-rc7 vydané 9. května. Linus řekl:

Takže věci byly poměrně v klidu a pokud se neobjeví něco význačného, věřím, že tohle -rc bude poslední. Všechny detaily lze nalézt v kompletním changelogu.

Stabilní aktualizace: aktualizace stabilních jader 2.6.32.40, 2.6.33.13 a 2.6.38.6 byly vydány 9.května. Každé obsahuje dlouhý seznam důležitých oprav.

Citáty týdne: Greg Kroah-Hartman, Andrew Morton

Překlad jádra umožní koncovým uživatelům modifikovat zařízení způsobem, který jeho výrobce běžně nenabízí, jako například změnit téma zařízení změnou systémových ikon a odstranit/změnit systémové komponenty. Berte na vědomí, že Sony Ericsson toto nedoporučuje.

-- ...ale řeknou vám, jak na to

Takové lidi snadno zvládnu, protože jsem o trochu větší a mám spoustu zkušeností z doby, kdy jsem několik let dělal vyhazovače v punk-rockovém baru.

-- Zdroj schopností Grega Kroah-Hartmana

Prostě nedokážu pochopit, proč vy lidi od dister potřebujete patchovat jádro, když by stačilo přidat jeden řádek do initscriptů. Mám podezření, že svoji roli tu hraje neschopnost.

-- Andrew Morton

Stabilní stránky

napsal Jonathan Corbet, 11. května 2011

Když proces zapíše do stránky v paměti obsahující data souboru (ať už pomocí mapování do paměti nebo systémovým voláním write()), označí se stránka jako špinavá a časem je nutné ji zapsat zpět na úložiště. Kód zpětného zápisu [writeback], když se k dané stránce dostane, ji označí jako pouze pro čtení, nastaví příznak „probíhá zpětný zápis“ [under writeback] a naplánuje I/O operaci. Ochrana před zápisem neslouží k tomu, aby se zabránilo v tom stránku měnit; účelem je detekovat další změny, které by vyžadovaly další zpětný zápis. Současná jádra ve většině případů umožní procesu modifikovat stránku, na které probíhá zpětný zápis.

Ve většině případů to také funguje bez problémů. Nejhorší varianta je, že druhý zápis do stránky začne předtím, než začne I/O operace prvního zpětného zápisu; v takovém případě budou nová data zapsána na disk již při první I/O operaci a později se naplánuje druhý, redundantní zápis. Tak jako tak se data dostanou na úložiště, což je cílem.

Jsou ale případy, kdy je modifikace stránky, když probíhá zpětný zápis, špatným nápadem. Některá zařízení dokáží kontrolovat integritu, což znamená, že k datům zapsaným na disk se vypočítá kontrolní součet a ten se porovná s kontrolním součtem, který spočítalo a zapsalo jádro. Pokud se data změní po vypočítání kontrolního součtu jádrem, kontrola selže, což vede na podivnou chybu při zápisu. O změny dat mohou zakopnout i implementace softwarového RAIDu. Výsledkem těchto problémů je to, že vývojáři pracující v oblasti souborových systémů již před nějakou dobou dospěli k přesvědčení, že je nutné, aby jádro podporovalo „stabilní stránky“, u kterých je garantováno, že se během zpětného zápisu nezmění.

Když se Jaderné noviny v únoru stabilními stránkami zabývaly, Darrick Wong zaslal patch, který měl problém vyřešit. V situacích, když se používá kontrola integrity, by jádro před zahájením zpětného zápisu vytvořilo kopii stránky. Vzhledem k tomu, že nikdo v uživatelském prostoru by o kopii nevěděl, bylo by garantováno, že během zápisu nebude poškozena. Patch řešil problémy v případě kontroly integrity, ale dodatečné operace kopírování jsou drahé. Vzhledem k tomu, že se považovalo za žádoucí poskytnout stabilní stránky ve všech situacích, byla taková cena odmítnuta.

Darrick se tedy vrátil s novou sadou patchů, která používá jiný – a jednodušší – přístup. V krátkosti s tímto patchem jakýkoliv pokus zapsat do stránky, na které probíhá zpětný zápis, jednoduše počká, dokud se zápis nedokončí. Není potřeba kopírovat stránky nebo používat jiné triky, ale tento přístup má také svou cenu.

Jak bylo zmíněno výše, když probíhá zpětný zápis, stránka se označí jako pouze pro čtení; také je zde příznak, který říká, že probíhá zpětný zápis. Všechny tyto kousky jsou zde k tomu, aby se zachytily zápisy do takové stránky. A aby to bylo ještě jednodušší, vrstva VFS již má zpětné volání [callback] (page_mkwrite()), kterým souborové systémy upozorní na to, že stránka pouze pro čtení byla změněna na zapisovatelnou; Darrick jenom musel změnit to, jak tato volání page_mkwrite() fungují, když probíhá zpětný zápis.

Některé souborové systémy page_mkwrite() vůbec nenabízejí; pro ty Darrick vytvořil obecnou funkci empty_page_mkwrite(), která zamkne stránku, počká na dokončení zpětného zápisu a pak zamknutou stránku vrátí. Komplikovanější souborové systémy ale mají obsluhy page_mkwrite(), takže Darrick musel přidat podobnou funkcionalitu pro ext2, ext4 a FAT. Btrfs implementuje stabilní stránky již nějaký čas interně, takže tam nebyly potřeba žádné změny. Ukazuje se, že Ext3 obsahuje nějaké komplikované interakce s žurnálovací vrstvou, které implementaci stabilních stránek ztěžují; vzhledem k tomu, že invazivní změny v tomto souborovém systému nejsou momentálně vítány, podpora stabilních stránek v něm možná nebude nikdy.

Objevily se obavy, že tento přístup by mohl zpomalit aplikace, které opakovaně zapisují do stejné části souboru. Před touto změnou zpětný zápis nijak nezpomalil další zápisy; po ní budou muset čekat. Darrick zkusil několik benchmarků, tento přístup otestoval a zjistil, že pokles výkonu je až 12 %. Toto zpomalení není vítáno, ale zdá se, že konsenzus je takový, že jenom málo aplikací na takový problém skutečně narazí. Opakované přepisování dat je relativně vzácné; zainteresování vývojáři říkají, že ani neví o žádném případu ze skutečného světa, který by mohli otestovat.

To, že o žádných neví, samozřejmě neznamená, že žádné neexistují. Problémy, které taková změna způsobí, se mohou projevit až za několik let, když se kód konečně dostane od distributorů k uživatelům; v té době už bude příliš pozdě vzít něco zpět. Pokud jsou tu aplikace, které by na tuto změnu mohly reagovat špatně, je potřeba o tom dát vědět teď. V opačném případě přínosy stabilních stránek pravděpodobně zajistí, že budou ve většině případů přijaty.

Ftrace, perf a ABI pro sledování

napsal Jonathan Corbet, 11. května 2011

Arjan van de Ven nedávno nahlásil, že změna v 2.6.39 týkající se toho, jak jádro předává data ze sledovacích bodů, rozbíjí powertop; požádal, aby byla částečně vzata zpět. Následná diskuze se týkala již známého problému ohledně toho, jak se sledovací body míchají s jaderným ABI. Také ale odhalila vážné neshody o tom, jak by se měla data ze sledování předávat, a možná i to, jakým směrem se toto rozhraní bude ubírat v budoucnu.

Každý sledovací bod v jádře obsahuje několik polí, které obsahují hodnoty relevantní k události, která je jím dokumentována. Například sledovací bod sched_switch, který se spustí, když plánovač přepíná mezi procesy, zahrnuje ID obou procesů, jejich priority a tak dál. Každý sledovací bod má také několik „společných“ polí včetně ID procesu, jeho příznaků a hodnoty preempt_count; když se data čtou v binární podobě, objeví se tyto hodnoty na začátku přečtené struktury.

Před vývojovým cyklem 2.6.32 mezi tato společná pole patřilo i ID skupiny vláken (thread group ID); tato hodnota byla odstraněna v září 2009. Pohled na zdrojové kódy powertop ukazuje, že program stále očekává, že tam toto pole bude (i když ho nepoužívá); interně definovaná struktura pro data ze sledování obsahuje pole tgid. Změna tedy měla powertop rozbít už tenkrát a taky by se tak stalo, kdyby nedošlo k další změně: ve stejný den Steve Rostedt přidal jiné společné pole lock_depth, které hlásilo, jestli současný proces držel velký jaderný zámek (big kernel lock, BKL). U tohoto pole se nikdy nepředpokládalo, že by mělo zůstat natrvalo: koneckonců jeho účelem bylo pomoci BKL odstranit.

V 2.6.39 bylo podle lock_depth odstraněno a powertop přestal fungovat. Arjan si následně stěžoval; také dodal patch, který přidává pole vyplněné nulami na místo, kde býval lockdepth. Steve s patchem nesouhlasí, protože kdyby powertop používal sledovací ABI správně, nikdy by fungovat nepřestal. Jádro exportuje informace o každém sledovacím bodu; pro výše zmíněný sched_switch lze tyto informace prozkoumat z příkazové řádky:

# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format
name: sched_switch
ID: 51
format:
    field:unsigned short common_type; offset:0; size:2;	signed:0;
    field:unsigned char common_flags; offset:2; size:1; signed:0;
    field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
    field:int common_pid; offset:4; size:4; signed:1;

    field:char prev_comm[16]; offset:8; size:16; signed:1;
    field:pid_t prev_pid; offset:24; size:4; signed:1;
    field:int prev_prio; offset:28; size:4; signed:1;
    field:long prev_state; offset:32; size:8; signed:1;
    field:char next_comm[16]; offset:40; size:16; signed:1;
    field:pid_t next_pid; offset:56; size:4; signed:1;
    field:int next_prio; offset:60; size:4; signed:1;

Steve říká, že správně napsaný program by tento soubor měl načíst a offsety dat, která ho zajímají, zjistit z něj. Linus podle všeho souhlasil, že by bylo hezké, kdyby věci fungovaly takto, ale na to nedošlo. Místo toho přinejmenším jeden program začal záviset na formátu binárních dat, která jádro exportuje. To stačí k tomu, aby se tento formát stal součástí jaderného ABI; rozbití programu se počítá jako regrese a Arjanův patch tedy byl začleněn.

Stevovi se tento výsledek nelíbil; naprosto odporuje snaze, která byla věnována tomu, aby se sledovací body mohly měnit bez rozbití aplikací. Alternativou je podle něj pohřbít jádro v bordelu pro kompatibilitu:

Důvodem, proč se sledovací body doteď příliš neměnily, je, že ke změnám v návrhu jádra nedochází často. Ale dochází k nim a do budoucna předpovídám, že jádro bude muset obsahovat velký počet „zastaralých sledovacích bodů“ a budeme je muset udržovat navěky.

Co se stane, když někdo vytvoří nástroj, který bude analyzovat souborový systém XFS pomocí jeho 200+ sledovacích bodů? Stane se ze všech sledovacích bodů ABI?

Myšlenku, že by se ze sledovacích bodů XFS stala součást jaderného ABI, označil Dave Chinner jako bláznivé řeči, ale tyto sledovací body se od ostatních nijak neliší. I z nich by se opravdu mohlo stát jaderné ABI.

Steve měl také problém s velikostí událostí: odstranění lock_depth kromě toho, že odstranilo (nyní) nesmyslný kus dat, také zmenšilo každou událost o 4 byty. Vždycky je tlak na to omezit režii sledování a omezit velikost dat kopírovaných do uživatelského prostoru je toho součástí; přidat pole kvůli odsazení jde proti tomuto cíli. David Sharp (z Googlu) se přidal a poznamenal, že na velikosti dat jim záleží hodně:

Velikost událostí je pro nás obrovsky důležitá. Podívejte se na patche, které ke sledování zasíláme: spousta z nich se zabývá omezením velikosti událostí. Většina patchů, které udržujeme interně, se týká omezení velikosti událostí. Na našich strojích je paměť jedním z nejvíce vzácných zdrojů a my si nemůžeme dovolit používat velké buffery pro sledování.

Steve doufal, že odstraní i další společná pole (změna, kterou Google interně již používá); to je teď pasé. Sledovací body jsou podle všeho ABI, přestože informace, které poskytují, v jádře již nedávají smysl.

Zbytek diskuze tvořila hádka mezi Stevem a Ingo Molnárem, kteří chtěli tento problém na někoho hodit a určit, jak věci budou fungovat v budoucnu. Ingo zaútočil na Steva za jeho odpor vůči neměnným sledovacím bodům, obvinil ho, že ftrace spravuje jako fork perfu v jádře (přestože ftrace existovalo dřív) a řekl, že perf musí funkce ftrace převzít:

perf je v podstatě UI k ftrace a API jsou navržena lépe, čistěji a robustněji. Podívej se na nástroje, které kolem toho ABI vyrašily takřka přes noc. ftrace se v minulosti vyvíjel přes mnoho iterací a perf je jednoduše další logický krok.

Také vyhrožoval tím, že přestane od Steva přetahovat změny sledování.

Steve oplátkou obvinil perf z toho, že se přilepil na infrastrukturu ftrace a pak vyexportoval binární struktury ftrace přímo do uživatelského prostoru. Obvinil Inga, že blokuje změny, které mají situaci zlepšit (například vytvoření samostatného adresáře pro stabilní sledovací body, který byl odsouhlasen na Jaderném summitu 2010), a stěžoval si, že Ingo ignoruje jeho pokusy vytvořit sledovací infrastrukturu, která by fungovala pro všechny. Také ještě jednou zmínil obavy, že sledovací body zakované do kamene zpomalí vývoj jádra.

Přes to všechno je Steve ochoten pracovat na sjednocení ftrace a perfu, za předpokladu, že to nebude znamenat zahození ftrace:

Teď, když se na poli sledování objevil perf, dám ty dva rád dohromady. Ale neshodnu se s tebou na tom, jak to udělat. Nezahodím ftrace kvůli tomu, abych pracoval na perfu. Ftrace má příliš mnoho uživatelů, kteří žádají vylepšení, a já je hodlám dál podporovat. Důvodem je to, že upřímně nevěřím, že by perf dokázal v blízké budoucnosti (pokud vůbec někdy) dělat to, co tito uživatelé chtějí. Neopustím úspěšný projekt jenom kvůli tomu, že máš pocit, že je to fork.

Zdá se tedy, že i když mezi vývojáři v této oblasti zjevně panují neshody, měl by zde být prostor pro řešení, které bude fungovat pro všechny. Důraz se zjevně bude čím dál tím více klást na perf, ale i přes Ingovu touhu se bude dál vyvíjet i ftrace. Možná uvidíme snahy tlačit aplikace k tomu, aby používaly knihovny, které je odstíní od změn sledovacích bodů, ale zatím musíme považovat každý sledovací bod přidaný do jádra za součást ABI; vzhledem k tomu by vývojáři měli revidovat nové sledovací body pečlivěji než doteď. Při troše štěstí se osazení Linuxu sledovacími nástroji – které se během posledních let značně zlepšilo – bude zlepšovat i nadále.

       

Komentáře

[x00]

Z ludi ako Andrew Morton, Ulrich Drepper a im podobnich sa mi chce vracat.

[R]

Mne zase z ludi ako ty.

[lunik13]

To bude plodna diskuse!

[qpal]

To zas bude v diskuzi nablito..

[koudy]

Vsichni blili jako sakali, jen pan "x00" potichu zvracel ;)

[Shadow]

Doporučuji podívat se na kontext. Andrewovi dal Jeff Mahoney, který patch poslal, za pravdu. Dokonce uvedl, že přesně to ho s kolegy napadlo, když patche posílali. Takže bych být tebou místo rychlých soudů chvíli přemýšlel. Ale zase co čekat od anonymů, kteří se vynoří, do někoho si kopnou, a pak zase někam zalezou.

I'm suspecting that trolling is involved.

[jarin]

... pole lock_depth, které hlásilo, jestli současný proces držel velký jaderný zámek (big kernel lock, BKL). U tohoto pole se nikdy nepředpokládalo, že by mělo zůstat natrvalo ...

V tom bude ten problém. Proč vývojáři strkají do veřejného ABI něco, co tam nemá být natrvalo. Základní pravidlo pro vytváření API/ABI je právě dělat to s rozmyslem, protože co se tam jednou objeví, to se dlouho a těžko odstraňuje.

[trekker.dk]

Háček je v tom, že zrovna v tomhle případě se dané ABI sice exportuje, ale má se používat nějakým způsobem, který by zabránil problémům...

[jarin]

Tohle je ale součást toho problému. Je to dostupné zvenku, tak to lidi používají. V podobných případech není možné spoléhat na to, že někdo čte dokumentaci a řídí se jí. Zrušit to znamená naštvat uživatele (vývojáře powertop) a to by si žádný autor SW neměl dovolit.

[trekker.dk]

Je to dostupné zvenku, tak to lidi používají.

Ano, cílem JE, aby to bylo dostupné zvenku. Jenže za nějakých podmínek. Informace, které z jádra nejde nijak vytáhnout, jsou k ničemu.

Zrušit to znamená naštvat uživatele (vývojáře powertop)

Dotyčný vývojář něco použil blbě, ergo je to blbec a pokud bude naštvaný, může si za to sám...

Jo, kdyby šlo o nějaké ABI ve smyslu strč do jádra tuhle strukturu a někde se změní IP adresa, tak neřeknu ani slovo (a protože se toho jádro drží, ještě pořád funguje ifconfig). Ale když jde na struktury 1:1 spjaté s tím, jak jádro funguje vevenitř, tak to pardon, ale nikdo příčetný nemůže očekávat, že budou stabilní.

[jarin]

Jenže takový vývojář potom dělá linuxu špatnou reklamu. Bude tvrdit, že mu vývojáři jádra rozbíjí aplikace a přidělávají práci. Prostě je při tvorbě veřejně přístupných částí potřeba dodržovat maximálně defenzivní styl (musí se brát v potaz i nejblbější uživatelé), takže zpřístupňovat měnící se části je chyba. Od začátku to mělo být řešeno pomocí knihovny, jak je psáno v článku.

[trekker.dk]

A knihovna zabrání ve čtení dat přímo z jádra jak? Nijak.

[Atom321]

Tak, že bude přibalená k jádru a bude jednodušší použít tu knihovnu, než se crcat s jaderným API.

[trekker.dk]

Jenže to k ničemu nebude, protože akorát posuneš problém z jádra do userspace. Tzn. události buď budou furt velké (= abys to mohl rozumně používat, budeš se muset "crcat" s jaderným ABI), nebo tam zatáhneš nekompatibility

[stativ]

Problém je v tom, že nikdo nepočítal s tím, že se z toho stane ABI.

[sigma]

Nebude problém spíš v tom, že vůbec může dojít k tomu, že se "z toho stane ABI"? To se jako stane samo? To není někde na jednom místě jasně napsáno co je součástí jaderného ABI se všemi důsledky (údržba na věčnost)? Nebo to někdo přidal do zdokumentovaného ABI? Pak odvedl špatnou práci, a nikdo jiný na to účinně neupozornil.

[stativ]

To co navrhuješ je ideální stav. Realita v kernelu je taková, že jakmile na něčem začnou stavět userspace aplikace, tak se z toho chtě nechtě ABI stane, protože vývojáři jádra razí cestu „nikdy nerozbít userspace.“

Je smutné, že kvůli jedné špatně napsané (ale rozšířené) aplikaci se řeší, že se ze sledovacích bodů oficiálně stane ABI.

[trekker.dk]

Vždycky mě pobaví ty Corbetovy komentáře na konci... v tomhle případě je to něco jako "máme nevyřešené problémy, děláme ptákoviny, kvůli kterým je jádro pomalejší, jenom protože někdo něco špatně použil, ale všechno je skvělé a všechno se vyřeší."

[kralyk z abclinuxu]

Že by měl powertop parsovat nějaký data ze sysfs a následně na základě nich v runtime sestavit strukturu, kterou bude s jádrem komunikovat, to mi přijde slušně řečeno trhlé.
Nemůže si prostě powertop naincludovat tu strukturu z nějakého jaderného .h? Pak by v podstatě stačilo překompilovat pro každou novou verzi jádra, podobně jako se to dělá s moduly.

[chrono]

Keby chceli, tak vyrobia nejaký program, ktorý im ten súbor rozparsuje a ten hlavičkový súbor im to vytvorí (problém ale je, že by sa tak nedal vyrobiť program, ktorý by fungoval s viacerými verziami jadra).

[trekker.dk]

Že by měl powertop parsovat nějaký data ze sysfs a následně na základě nich v runtime sestavit strukturu, kterou bude s jádrem komunikovat, to mi přijde slušně řečeno trhlé.

Taky to trhlé je, proto existuje lepší řešení. Powertop nepotřebuje všechna pole, která od jádra dostane (příkladem budiž to tgid, které víc než rok neexistuje). Takže ta struktura pro data může být napevno vytvořená už při překladu, při spuštění se proleze ten soubor ze sysfs, zjistí se offsety požadovaných polí a podle nich se načtená binární data ze sledování rozstrkají do té struktury.

Nemůže si prostě powertop naincludovat tu strukturu z nějakého jaderného .h?

Tohle je slušně řečeno trhlé. Změníš verzi jádra a přestane ti to fungovat.

[Ed]

Co je na tom divneho? Z popisu struktury zjisti, kolik bytu bude potrebovat, naalokuje buffer a preda ho jadru. Kdyz potom bude potrebovat (dejme tomu) sched_switch::common_pid, nejaka funkce mu vrati bufer[4]+(buffer[5]<<8)+(buffer[6]<<16)+(buffer[7]<<24). (plus casty)

Staci teda napsat trivialni knihovnicku, nebo pouzije neco jako libASN1. V cem je teda problem, krome lenosti vyvojare powertopu?

[kralyk z abclinuxu]

nejaka funkce mu vrati bufer[4]+(buffer[5]<<8)+(buffer[6]<<16)+(buffer[7]<<24). (plus casty)

Krása
Já neříkám, že to nejde, jasně že to jde, ale nepřijde mi to jako moc čisté řešení...

[Ed]

Co je na tom necisteho? :)

[jarin]

Minimálně bych si to netroufnul napsat, když budou ostatní vývojáři vědět, kde bydlím.

[Ed]

Muzes byt konkretnejsi? Co se ti na tom nezda? A ostatni vyvojari ceho? Podobny pristup se pouziva, pokud presna definice typu neni znama behem prekladu - treba v SNMP, v datovych parserech ...

[Peter Fodrek]

Kedy mozme ockavat statitisku 2,6.39 , kto ju napisal. Lebo ta je zaujinva vysla v racmi toho isteho clanku 12.5?

Specilne pre ludi okolo hard realtime, kde su hlaven firmy Pengutronix a linutronix a top ludia Thomas Gleixner a Ingo Molnar ....

[trekker.dk]

Kedy mozme ockavat statitisku 2,6.39

Budeš si muset přečíst originál, s článkem se statistikami je moc práce a není tam moc zajímavého, takže překlad není.

[Peter Fodrek]

ten mam precitany, som predplatilel linux weekly news.

[geebranz]

Stable sites

Recognize