Jaderné noviny – 21. 4. 2011: Swapování po síti

2. 5. 2011 | Jirka Bourek | Jaderné noviny | 4490×

Aktuální verze jádra: 2.6.39-rc4. Citáty týdne: Linus Torvalds. DISCONTIGMEM, !NUMA a SLUB. Racionalizace stromu ARM. Bezpečné swapování po síti.

Obsah

• Aktuální verze jádra: 2.6.39-rc4
• Citáty týdne: Linus Torvalds
• DISCONTIGMEM, !NUMA a SLUB
• Racionalizace stromu ARM
• Bezpečné swapování po síti

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

Současné vývojové jádro je 2.6.39-rc4 vydané 18. dubna. Linus:

Věci už se bohužel přestaly zklidňovat. V -rc4 jsme měli více commitů než v -rc3 a já opravdu doufám, že tento rostoucí trend nebude pokračovat.

Jediná věc, která v tomto vývojovém cyklu působila problémy, jsou změny v připojování do blokové vrstvy, a od -rc4 by problémy, které jsme měli s MD, snad měly být za námi. Na této frontě tedy děláme pokroky také.

Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: 17. dubna vyšlo 2.6.34.9, 15. dubna 2.6.32.37 a 2.6.33.10 (rychle následována jádry 2.6.32.38 a 2.6.33.11, která opravovala problém v síťovém protokolu RDS.) 14. vyšlo 2.6.38.3.

V době psaní tohoto článku se revidují 2.6.32.39, 2.6.33.12 a 2.6.38.4; očekávat je lze někdy 21. dubna.

Citáty týdne: Linus Torvalds

Ve skutečnosti jsou jenom dva přijatelné modely vývoje: „přemýšlej a analyzuj“ a „roky a roky testování na tisících strojů“. Tyto dva opravdu fungují.

-- Linus Torvalds

DISCONTIGMEM, !NUMA a SLUB

napsal Jonathan Corbet, 20. dubna 2011

Jádro má dva způsoby, jak se vypořádat se systémy které mají velké díry v adresovém prostoru fyzické paměti – DISCONTIGMEM a SPARSEMEM. DISCONTIGMEM je z těch dvou starší, je napůl označený za zastaralý a zdá se, že je z jádra (pomalu) vytěsňován. Některé architektury ho ale stále používají. Nedávné změny (a jimi způsobené pády) ukazují, že existují nějaká zajímavá nedorozumění o tom, jak se s DISCONTIGMEM pracuje v jádře.

Problém je následující: DISCONTIGMEM sleduje různé rozsahy paměti tak, že každý vloží do samostatného virtuálního NUMA uzlu. Výsledkem je, že systém běžící v tomto režimu může ukazovat, že má víc NUMA uzlů, i když podpora pro NUMA není zapnuta. To zjevně většinou funguje dobře, ale nedávno to způsobilo nějaké pády ve SLUB alokátoru, který nečeká více NUMA uzlů na systému, který není NUMA.

Strhla se překvapivě prudká diskuze o tom, čí je toto nedorozumění chyba a jak ji opravit. Mezi možnosti patří změnit DISCONTIGMEM tak, aby se takto „nezneužíval“ (podle některých) koncept NUMA; to by mohlo být dlouhodobé řešení, ale chyby existují teď a jak to řekl James Bottomley: Tohle je potřeba opravit ve -stable. Opravdu si nemyslím, že přepis DISCONTIGMEM by ve -stable sérii byl to nejlepší. Další možností je vynutit zapnutí podpory NUMA, když se používá DISCONTIGMEM; tím by se ale mohlo zvětšit jádro na embedded systémech a navíc to znamená přijmout podivný koncept, že jednoprocesorové systémy mohou být NUMA. Jádro by se dalo opravit tak, aby se dokázalo vyrovnat s nenulovými NUMA uzly vždy; to by znamenalo výrazný audit kódu, protože problémy nemusí být omezeny na SLUB alokátor. SLUB alokátor by bylo možné zakázat na systémech, kde je NUMA vypnuto a používá se DISCONTIGMEM, ale i tady by se mohly objevit problémy jinde. Také by šlo urychlit proces vytěsnění DISCONTIGMEM z jádra – to by ale nebylo použitelné do stabilních řad.

V době psaní tohoto článku diskuze pokračuje; není jisté, jako podobu bude mít konečné řešení. Problém je záludný a nezdá se, že by k němu existovaly snadné opravy.

Racionalizace stromu ARM

napsal Jonathan Corbet, 19. dubna 2011

Podpora architektury ARM v jádře je jednou z nejrychleji se pohybujících částí projektu, který jako celek rozhodně pomalý není. Nedávné obavy o stav kódu ve stromě ARM ale hrozí významným zpomalením vývoje a někteří vývojáři mají obavy z toho, že podpora pro některé platformy může být pozdržena na neomezeně dlouhou dobu. Situace pravděpodobně není tak špatná, ale aby se vývoj ARM dostal zpátky na správnou cestu, je rozhodně potřeba provést nějaké změny.

Hlavní správce ARM Russell King se nedávno díval na patche ARM v linux-next a nebyl potěšen tím, co viděl. Přibližně 75 % ze všech změn architektur se týkalo architektury ARM a tyto změny přidávají nějakých 6 000 řádků kódu. Část z toho je rozhodně ospravedlněna tím, že nové ARM procesory a desky se objevují téměř denně, ale i tak je to problematické v prostředí, kde se volá po tom, aby se kód zmenšil. Russell tedy navrhl: Prosím, zamyslete se na chvilku, jak na tohle během příštího začleňovacího okna zareaguje Linus..

Jak se ukazuje, nebylo nutné přemýšlet moc dlouho: Linus se objevil a řekl vývojářům ARM, co mohou očekávat:

Nápověda pro všechny v konferenci arm: podívejte se na dirstat, který poslal rmk. Jestli se vaše „arch/arm/{mach,plat}-xyzzy“ objevuje hodně často, je dost možné, že váš strom nepřetáhnu, pokud ty změny nebudou představovat odstranění spousty kódu.

Lidi si musí uvědomit, že nekončící množství nového zbytečného kódu platforem je problém, a protože mohu akorát říci „pokud to nebude vypadat, že se snažíte to napravit, přetahovat od vás nebudu“, udělám nakonec přesně tohle.

Přesně v době, kdy se tak rozhodnu.

Před nějakou dobou většina správců subplatforem ARM začala spravovat své vlastní stromy a požadavky na přetažení zasílat přímo Linusovi. Tento krok dával smysl; velikost a rozdílnosti ve stromě ARM brání jedinému správci na nejvyšší úrovni všechno stíhat. Také to ale vede k situaci, kde není moc velká kontrola a vede to ke spoustě duplikovaného kódu. Jak to řekl Arnd Bergmann:

V současnosti každá subarchitektura v arm implementuje mnoho ovladačů (irq, clocksource, gpio, pci, iommu, cpufreq, ...) Tyto ovladače jsou často kopiemi ovladačů již existujících s malými modifikacemi nebo (hůře) nezávisle napsané ovladače pro stejné IP bloky. V některých případech jsou to kopie ovladačů pro věci, které jsou přítomny na jiných architekturách.

Jasným řešením je vytáhnout více kódu ze subplatforem, najít společné části a odstranit duplikace. Všichni chápou, že taková snaha by mohla výrazně omezit množství kódu v ARM stromě; strom by zároveň s tím byl obecněji použitelný a lépe spravovatelný. na tom už se začalo pracovat; například lze uvést práci Thomase Gleixnera na konzolidaci ovladačů pro čipy řídící přerušení. Rafael Wysocki a Kevin Hilman pracovali na sjednocení kódu pro správu paměti a Sascha Hauer má patch „umravňující bláznivé soubory s daty hodin“.

Z této práce by mohly profitovat i další architektury mimo ARM. Například se přišlo na to, že většina GPIO ovladačů vypadá velmi podobně. Koneckonců i vývojáři hardwaru s tou největší představivostí mohou přijít jenom na omezený počet způsobů, jak řídit drát se dvěma či třemi stavy. Jádro obsahuje neuvěřitelný počet GPIO ovladačů; pokud by se většina z nich dala omezit na deklaraci toho, se kterými do paměti mapovanými I/O bity je potřeba pracovat, aby se přečetl a změnil stav linky, mohlo by zmizet hodně kódu.

Také se mluví o reorganizaci ARM stromu tak, aby většina ovladačů přestala žít v adresářích s kódem specifickým pro subplatformu. Jakmile bude možné najít všechny ovladače specifického typu na jednom místě, bude mnohem snazší najít duplikáty a abstrahovat společné funkce.

Všechna tato práce bude ale vyžadovat čas a příští začleňovací okno se má otevřít za méně než dva měsíce. Jakákoliv práce, která by se mohla začlenit do 2.6.40, by teď měla být skoro hotová; a většina věcí, která toto kritérium splňuje, ničím nevyniká: přidávají nové platformy, desky a ovladače. Russell se obává, že tato práce již nebude začlenitelná:

Budeme někdy schopni vložit Johnův kód do jádra? Upřímně nemám tušení. Co ale vím, je, že pokud nezačneme dělat něco, co by vyřešilo problém, který dnes máme s množstvím kódu pod arch/arm a s neustálým ruchem v tomto kódu, nikdy nebudeme schopni do jádra přidat podporu pro nové platformy v jakékoliv podobě.

Russell má občas tendence věci dramatizovat, což by mohlo čtenáře vést k tomu výše uvedené přehlížet, ale tyto obavy nemá jenom on. Mark Brown má obavy, že vývoj ARM se na několik měsíců zastaví; také vyjádřil pochybnosti nad celým nápadem, že by se strom ARM měl zmenšit, než mu bude opět povoleno růst:

Říkáme lidem, že mají pracovat na náhodných zlepšeních více či méně souvisejícího kódu. To nevypadá příliš rozumně a rozhodně to bude odrazovat nové přispěvatele (jako lidi, kteří se pokoušejí zaslat nové platformy, mnoho z nich jsou nováčci, co se práce na hlavní řadě týče), protože začít pracovat na méně známém kódu, když se ještě pořád snažíte učit a máte obavy, abyste někomu nešlápli na nohu nebo něco nerozbili, nemluvě o ospravedlnění takto stráveného času vedení, je docela velký skok.

Pokud se tyto obavy vyplní, můžeme se dostat do situace, ve které jádro ztratí velkou část své hybnosti – jak ohledně podpory nového hardware, tak ohledně příspěvků od výrobců. Cena takového výsledku by mohla být poměrně velká; není překvapením, že lidé mají obavy.

Ve skutečném světě nicméně takto ošklivý vývoj událostí není pravděpodobný. Nikdo neočekává, že by strom ARM mohl být opraven do začleňovacího okna 2.6.40; ani Linus, i přes názory, které dal jasně najevo, není tak nerozumný. Ve skutečnosti v současnosti pracuje na patchi pro git, díky kterému by práce na pročištění ARM nevypadala tak špatně ve statistikách. V blízké budoucnosti není potřeba kompletní řešení; je potřeba jasný signál, že komunita ARM vývojářů na takovém řešení pracuje. Nějaké počátky práce na pročištění, opravy těch největších prohřešků a plán pro následující cykly by měly postačovat, aby se Linusův Hněv odložil na další vývojový cyklus. Pokud poté věci budou pokračovat správným směrem, mělo by nadále být možné přidávat podporu pro nový hardware.

Pozorovatelé mohou být v pokušení považovat celou tuto epizodu za černý puntík pro vývojovou komunitu jádra. Jak můžeme provozovat profesionální vývojový projekt, když na celou architekturu může padnout takováto nejistota? Ve skutečnosti tu ale vidíme příklad toho, jak se komunita pokouší myslet na budoucnost. Nacpat do jádra více a více kódu pro ARM zajistí, že současný hardware bude fungovat, ale v dlouhodobém měřítku nikdo nebude šťastný z toho, když se jádro zhroutí vlastní vahou. Se štěstím nějaká odmítnutí dnes pomohou vyhnout se mnohem významnějším problémům za několik let. Ti z nás, kdo mají v plánu stále pracovat na Linuxu (a používat ho), z toho potom budou těžit.

Bezpečné swapování po síti

napsal Jonathan Corbet, 19. dubna 2011

Swapování stejně jako zpětný zápis stránek funguje za velmi významných omezení. Možnost zapsat špinavé stránky zpět na úložiště je pro správu paměti kritická; je to jediný způsob, jak tyto stránky lze uvolnit pro další použití. Swapování tedy musí fungovat i za situace, kdy systém nemá téměř žádnou paměť, kterou by mohl postrádat. Zápis stránek na úložiště nicméně sám o sobě vyžaduje paměť – to je problém, který byl (pomocí fondů paměti [mempools]) vyřešen pro lokální zařízení, ale síťová zařízení přidávají problémy navíc a ty ještě nebyly vyřešeny zcela uspokojivě.

Samozřejmě se nejedná o nový problém; na LWN se článek o swapování na síťová bloková zařízení [network block devices, NBD] objevil téměř před šesti lety. Tehdy byly navrženy různé přístupy, ale začleněn nebyl žádný; uvidí se, jestli nejnovější pokus (zaslaný Melem Gormanem a založený na práci Petera Zijlstry) bude úspěšnější.

Jaderný alokátor stránek své poslední stránky rozdává jenom těm procesům, o kterých si myslí, že se snaží uvolnit paměť. Konkrétně daný proces musí mít nastaven příznak PF_MEMALLOC nebo TIF_MEMDIE; PF_MEMALLOC dává najevo, že proces právě pracuje na shlukování paměti nebo přímém znovuzískávání [direct reclaim]. TIF_MEMDIE znamená, že proces narazil na zabijáka při nedostatku paměti [out-of-memory killer] a pokouší se ukončit. Toto pravidlo by mělo sloužit k tomu, že když je potřeba uvolnit více paměti, nějaká by pro tento účel měla být volná; jeden aspekt tohoto mechanismu ale nefunguje příliš dobře: interakce se slab alokátory.

Slab alokátor si zabere celou stránku a rozdává ji po malých kouscích. Pokud proces označený PF_MEMALLOC či TIF_MEMDIE požádá slab alokátor o objekt, alokátor na splnění tohoto požadavku může použít rezervovanou stránku. Problém je, že její zbytek je poté dán k dispozici všem ostatním procesům, které si požádají; tak může být vyplýtván procesy, které situaci paměti zhoršují a ne zlepšují.

První věc, kterou dělá Melova série patchů, je tedy adaptace Peterova patche, který do slab alokátorů přidává víc informací. Do struct page přibývá nová pravdivostní hodnota (pfmemalloc), která informuje o tom, že daná stránka byla získána z rezerv; její příjemce s ní má podle toho pracovat. Slab i SLUB alokátory byly upraveny tak, aby tento příznak rozpoznaly a rezervovaly zbytek stránky pro vhodně označené procesy. Tato změna by mohla pomoci zajistit, že paměť bude v případě potřeby k dispozici, ovšem za cenu, že jiné alokace paměti mohou selhat, i když budou k dispozici volné objekty.

Dalším krokem je přidání GFP příznaku __GFP_MEMALLOC, který označí požadavky na alokaci, které mohou používat rezervy. Tento příznak odděluje označení urgentních požadavků na alokaci od stavu procesu – tato změna bude užitečná později v sérii patchů, kde by mohl chybět vhodný stav procesu. Bude zajímavé sledovat, za jak dlouho se nějaký vývojář pokusí tento příznak někde jinde v jádře zneužít.

Velkým problémem pro swapování po síti je, že pro zpracování síťových protokolů je potřeba paměť navíc. Pokud tedy má swapování po síti fungovat spolehlivě, musí síťová vrstva být schopna používat rezervy paměti. Poměrně velká část práce se sítí probíhá v obsluhách softwarových přerušení, které běží nezávisle na procesu. Příznak __GFP_MEMALLOC těmto obsluhám umožňuje přistupovat k rezervované paměti a byla přidána i nějaká další vylepšení.

Není ale žádoucí umožnit každé síťové operaci používat rezervy; bittorrent či prohlížeč webu nesmí mít možnost používat paměť, která je urgentně zapotřebí jinde. Pro označení socketů, které pracují na uvolnění paměti, slouží nová funkce sk_set_memalloc(). Alokace pro tyto sockety použijí příznak __GFP_MEMALLOC, zatímco všechny ostatní alokace budou mít normální prioritu. Předpokládá se, že takto budou označeny pouze sockety spravované jádrem; jakýkoliv socket, který končí v uživatelském prostoru, by neměl být schopen přistupovat k rezervám. Swapování přes souborový systém připojený pomocí FUSE tedy není něco, od čeho by se mělo očekávat, že to bude fungovat.

Je tu ale další problém: příchozí pakety nemají zvláštní příznak „je zapotřebí pro získání paměti“. Síťová vrstva tedy musí být schopna alokovat paměť pro všechny příchozí pakety alespoň na tak dlouho, než se podaří identifikovat ty důležité. Za tímto účelem všechny alokace pro příchozí data mohou přistoupit k rezervám, pokud je to potřeba. Jakmile je paket identifikován a spojen se socketem, lze zkontrolovat příznaky socketu; pokud byl paket alokován z rezerv a cílový socket není spojen se získáváním paměti, paket se hned zahodí. Tato změna by měla umožnit důležitým paketům dostat se do systému, aniž by se spotřebovalo příliš mnoho paměti pro nedůležitý provoz.

Výsledkem je, že systém by měl být schopen bezpečně swapovat přes síťové blokové zařízení. Tedy přinejmenším by to mělo být bezpečné, pokud je dost vysoký spodní vodoznak – ten určuje, kolik paměti se rezervuje. Systémy, které swapují po síti, mohou rezervy využívat relativně intenzivně, takže jejich správci by možná měli vodoznak zvýšit (k nalezení v /proc/sys/vm/min_free_kbytes). Poslední patch v sérii hlídá rezervy a začne omezovat procesy, které pracují na přímém znovuzískávání, pokud jsou rezervy vyčerpány. Cílem je zajistit, aby pro menší počet takových procesů zůstalo více paměti a aby mohly opravdu něco udělat. Úprava velikosti rezerv dynamicky by v dlouhodobém měřítku mohla být lepším řešením, ale tato vlastnost byla zatím opomenuta, aby série patchů nebyla příliš velká.

       

Komentáře

[multi]

Koneckonců i vývojáři hardwaru s tou největší představivostí mohou přijít jenom na omezený počet způsobů, jak řídit drát se dvěma či třemi stavy

Posledni dobou je vtipny i sam autor LWM.

[Peter Fodrek]

Mate na msyli jonathana Corbeta z Linux Weekly News (LWN)?

je len sefreadaktorom...

[Miloslav Ponkrác]

Také jsem zvědav na jejich definice I/O API tak, aby to fungovalo univerzálně. Až to tak 40× předělají, protže jim další zařízení čas od času ukáže, že se do jejich představy API nevejde, pak toho nechají.

[pc2005]

No ještě že mezi současným stavem a superideálním je mnoho stavů, kde se dá zachytit .

[Dusan]

Racionalizace stromu ARM

Tak to sa my fakt páči prístup hlavných vývojárov a správcov. Píšem si ďalšie plus prečo používať Linuxové distribúcie.

[Aleš Kapica]

Jediná věc, která v tomto vývojovém cyklu působila problémy, jsou změny v připojování do blokové vrstvy, a od -rc4 by problémy, které jsme měli s MD, snad měly být za námi. Na této frontě tedy děláme pokroky také.

No tak zrovna tohle bylo důvodem proč jsem se velmi rychle vrátil k jádru 2.6.38.4 Opravdu jsem neměl valné chuti reportovat bugy, jejichž příčina mi je záhadou.

[geebranz]

lots of tests

Rely