Jaderné noviny – 16. 5. 2013: Ošetřování výpadků stránek v uživatelském prostoru

3. 6. 2013 | Luboš Doležel | Jaderné noviny | 5240×

Aktuální verze jádra: 3.10-rc1. Citáty týdne: Dave Chinner, Will Deacon. copy_range(). Ošetřování výpadků stránek v uživatelském prostoru.

Obsah

• Aktuální verze jádra: 3.10-rc1
• Citáty týdne: Dave Chinner, Will Deacon
• copy_range()
• Ošetřování výpadků stránek v uživatelském prostoru

Aktuální verze jádra: 3.10-rc1

Aktuální vývojová verze jádra je 3.10-rc1 vydaná 11. května. Celkově bylo do hlavní řady během začleňovacího okna přetaženo 12 000 sad změn, což je nejvíce v historii. Přehled posledních významných věcí, co byly začleněny, najdete v originále článku.

Stabilní aktualizace: verze 3.9.2, 3.8.13, 3.4.45 a 3.0.78 vyšly 11. května; verze 3.2.45 vyšla 14. května.

Do oznámení verze 3.8.13 připsal Greg Kroah-Hartman následující: POZOR, toto je POSLEDNÍ vydání jádra 3.8.y, prosím přejděte na verzi 3.9.x. Je to konec životnosti, je to mrtvé, pohřbené a zapomenuté tak, že se o tom už nikdy nebudeme bavit. Myslím to vážně, přejděte, už to za to nestojí. Ale lidé z Canonicalu, kteří do Ubuntu 13.04 zařadili právě Linux 3.8, přecházet nebudou; podporu pro toto jádro oznámili až do srpna 2014.

Citáty týdne: Dave Chinner, Will Deacon

Množství rozbitého kódu, na který jsem narazil, stojí za zamyšlení. Přidal jsem komentáře vysvětlující, co je špatně, ale mám obavy, že některý kód by bylo lepší odtáhnout za barák, zakopat do hlíny až po krk a pak opakovaně přejíždět tupou sekačkou.

-- Dave Chinner: ne zrovna ohromen kódem shrinkeru

choice
 prompt „Nastavení BogoMIPs“
 default BOGOMIPS_MEDIUM
 help
  Hodnota BogoMIPs hlášená jádrem je přesně taková, jak zní:
  úplně k ničemu. Používá se ke kalibraci smyčky pro dělání
  prodlev, která za sebou může mít časovač naprosto nezávislý na
  taktu CPU.

  Ani to ale nezabránilo marketérům (a dokonce i lidem, co by toho
  mohli vědět více) v tom, aby porovnávali toto číslo mezi různými
  stroji a pak křičeli, když to činí méně než nějaká vysněná,
  očekávaná hodnota.

  Proto lze tuto volbu použít na to, abyste se vyhnuli
  nevyhnutelnému utrpení, když výše popsaná individua začnou parsovat
  /proc/cpuinfo.

 config BOGOMIPS_SLOW
  bool „Pomalé (starší stroje)“
  help
  Pokud porovnáváte pomalejší a rychlejší stroj, tak nastavte
  tuto hodnotu na jednom z nich.

 config BOGOMIPS_MEDIUM
  bool „Střední (výchozí)“
  help
  Hodnota BogoMIPS pro většinu lidí.

 config BOGOMIPS_FAST
  bool „Rychlé (marketing)“
  help
  Někteři lidé věří, že software běží s touto volbou
  rychleji. Pokud jste jedním z nich, tak zde zvolte Y.

 config BOGOMIPS_RANDOM
  bool „Náhodné (ještě více Bogo)“
  help
  Opravdové bogo v BogoMIPsech.

copy_range()

Kopírování souborů je běžnou operací na každém systému. Některé systémy souborů mají možnost kopírovací operace značně urychlit; takové Btrfs může jen přidat k datům referenci typu copy-on-write a protokol NFS zase může zažádat, aby kopírování proběhlo na serveru a data se nemusela přes síť dvakrát kopírovat. Většinou se ale kopíruje po staru; nejmazanější aplikace možná používají splice().

Během uplynulých let se objevily různé návrhy, jak operace kopírování urychlit (například reflink()), ale nikdy se nic nedostalo do hlavní řady. Poslední pokus je od Zacha Browna a nazývá se copy_range(). Jde o nové systémové volání:

int copy_range(int in_fd, loff_t *in_offset,
		   int out_fd, loff_t *out_offset, size_t count);

Smysl systémového volání je docela jasný: okopírovat count bajtů ze vstupu in_fd na výstup out_fd. Není to nikde napsané, ale mělo by jít o dva soubory na tom samém systému souborů.

Uvnitř jádra je do struktury file_operations přidáván nový člen copy_range(); každý systém souborů by měl implementovat rychlou operaci kopírování. Na vrstvě VFS není k dispozici žádná výchozí implementace, ale to je nedostatek, který by před začleněním byl opraven. Jestli na začlenění někdy dojde, to se teprve uvidí; tohle je téma, na které bychom našli spousty zahozeného kódu z předchozích pokusů.

Ošetřování výpadků stránek v uživatelském prostoru

Ošetřování výpadků stránek přísluší obvykle jádru. Jakmile se proces pokusí přistoupit k adrese, která aktuálně není mapovaná na adresu v RAM, pak jádro odpoví přidáním mapování stránky a podle potřeby stránku naplní daty ze sekundárního úložiště. Ale co když jsou data někde, kam se jádro jen tak nedostane? Pak možná nastal čas na to, aby zodpovědnost za výpadky stránek měl uživatelský prostor.

Jednou takovou situací, kdy se může ošetřování v uživatelském prostoru hodit, je živá migrace virtuálních strojů z jednoho systému na druhý. Migrace se může udělat tak, že se stroj zastaví, okopíruje se celý jeho paměťový prostor a opětovně se spustí. Ale adresní prostor může být velký a jen místy opravdu používaný; kopírování celého prostoru může znamenat, že se bude dělat zbytečně hodně práce a virtuální stroj bude dlouho vypnutý. Pokud by místo toho mohl být adresní prostor virtuálního stroje stránkován na požádání ze starého systému na nový, pak by restart mohl proběhnout rychleji a mohli bychom se vyhnout kopírování nepotřebných dat.

Živá migrace je u KVM nyní řešena pomocí dodatečného znakového zařízení. Tento způsob funguje, ale jakmile zařízení převezme část paměti, pak je tato odstraněna ze subsystému správy paměti. Takže není možné ji odswapovat, transparentní velké stránky nefungují a tak dále. Jednoznačně by bylo lepší přijít s řešením, kde by paměť stále zůstávala pod jadernou správou, ale uživatelský prostor by mohl řešit správu stránek. Patch od Andrea Arcangeli se tyto problémy snaží vyřešit pomocí několika nových voleb pro systémová volání.

První věcí je rozšíření systémového volání madvise() o volbu MADV_USERFAULT. Procesy mohou tuto operaci použít k určení, že uživatelský prostor bude řešit výpadky stránek v tomto prostoru. Po tomto volání jakýkoliv přístup k nenamapované oblasti paměti vyvolá signál SIGBUS; od procesu se pak očekává, že odpoví namapováním skutečné stránky tak, jak se popisuje dále. K volání madvise(MADV_USERFAULT) by mělo dojít hned po vytvoření paměťového prostoru; nebude fungovat, pokud jádro bude muset obsluhovat výpadky dříve, než se dozví, že by to měl dělat uživatelský prostor.

Na obsluze signálu SIGBUS je to, aby vyřešila výpadek stránky namapováním skutečné paměti na kýženou adresu. To je v současných jádrech možné pomocí funkce mremap. Problém s mremap() je v tom, že rozděluje strukturu virtuální paměťové oblasti (VMA) určené k popisu paměti v daných místech pro účely jádra. Častá volání mremap() vedou ke správě velkého počtu VMA, což je dosti nákladné. mremap() navíc klidně přepíše stávající mapování, což komplikuje odhalování chyb (nebo race conditions) v obsluze v uživatelském prostoru. Z těchto důvodů není mremap() ideálním řešením.

Andrea problém řeší novým systémovým voláním:

int remap_anon_pages(void *dest, void *source, unsigned long len);

Toto volání způsobí, že len bajtů od adresy source bude namapováno do adresního prostoru začínajícího na dest. Současně bude rozsah paměti source počínaje odmapován – stránky, které se tam původně nacházely, budou atomicky přesunuty do rozsahu v dest.

Andrea vytvořil malý testovací program, který ukazuje, jak se tato API mají používat.

Jak by se dalo čekat, jsou tu určitá omezení: source a dest musejí být zarovnané dle velikosti stránky, len musí být násobkem velikosti stránky, rozsah v dest musí být nenamapovaný a rozsah v source musí být plně namapovaný. Tato omezení jsou tu z toho důvodu, aby bylo možné v obsluze v uživatelském prostoru odhalit chyby; přemapování stránek přes stávající stránky by s sebou neslo velké riziko poškození obsahu paměti.

Jednou z pěkných funkcí patche je to, že na systémech s podporou transparentních velkých stránek je tyto možné stránky přemapovat pomocí remap_anon_pages() bez jejich rozdělení. Aby toto fungovalo, tak musí zarovnání adres a velikost pochopitelně odpovídat velkým stránkám.

Patch má v současné podobě řadu omezení. Volbu MADV_USERFAULT lze používat jen u anonymních stránek (které za sebou mohou mít maximálně swap). Úplnější implementace by možná mohla tuto funkci zvládat i u stránek, které mají za sebou soubor. Dále pak mechanismus sice nabízí podporu pro namapování stránek do RAM, ale už pak schází mechanismus k jejich odstranění; místo toho jsou tyto stránky odswapovány jako běžné anonymní stránky. Takže se nejededná o úplné řešení stránkování v uživatelském prostoru; jde spíše jen o háček pro načtení počátečního obsahu anonymních stránek z vnějšího zdroje.

Ale i s těmito omezeními je tato funkčnost užitečná ve virtualizaci. Andrea říká, že by se snad našlo i další využití; člověka napadá vzdálená RAM. Nejdřív se to ale musí dostat do hlavní řady jádra, což znamená, že ABI musí být důsledně zrevidováno. Zatím se patch nedočkal moc pozornosti; před zařazením se toto bude nejdřív muset změnit.

       

Komentáře

[petr_p]

Chápu, že lidi od virtualizace často znají jen x86_64, kde se se SIGBUS nepotkají, ale na jiných architekturách je to signál docela běžný (nezarovnaný přístup do paměti). Jak si představují, že proces rozliší důvod signálu?

[luky]

Jak si představují, že proces rozliší důvod signálu?

Prectenim polozky si_trapno v siginfo?

[petr_p]

Něco takového bych čekal, ale čekal bych, že zrovna tohle se bude v LWN řešit, protože jednotlivé položky siginfo_t jsou poněkud podspecifikované. Zrovna třeba si_trapno je vyhrazeno pro číslo hardwarové výjimky. Toto číslo je specifické pro platformu a přetěžovat jej pro softwarový výpadek bych si nedovolil.

[luky]

Ta konstanta ale muze mit klidne na kazde platforme jinou hodnotu, stejne jako spousta jinych konstant.

[JS]

Ja bych rekl, ze to byla Petrova pointa.. Ze se prave neda multiplatformne urcit, jakou by mela mit hodnotu ta konstanta pro vypadek stranky, kdyz kazdy HW pouziva jine konstanty.

Jinak mozna naivni otazka, ale jak komplikovane by bylo proste pridat dalsi signal?

[luky]

Vite treba o tom, ze mezi platformami se lisi i cisla signalu? A navic trapno je 4 bytovy integer, takze by se pro kernel mohly pouzivat zaporna cisla, ktera pravdepodobne zadny HW nepouziva.

[JS]

Ano, to me napadlo. Ale otazka je, co je to platforma. x86 se casto oznacuje za platformu, presto se HW ktery pripojujete muze dost lisit (a zapojeni CPU v systemu).

Ale neni duvod se rozcilovat. Nejsem expert pres x86.

[petr_p]

Byla nebyla. Bojím se, že se tam cpe hodnota přímo z nějakého registru. Bez validace. A nerad bych se dožil, aby výměnou procesoru, jehož výrobce dostane přesně stejný nápad s nikde nepoužitými zápornými číslu, mi začali padat procesy.

Prostě mi přijde zvrhlé ukládat nesouvisející hodnotu do něčeho, co má jiný význam. To už lepší mi přijde si_code. Nicméně sémanticky by dával smysl SIGSEGV.

[Sten]

Proč SIGSEGV? Když mmapuji paměť z flash disku a vytáhnu jej (takže mmap nemá odkud načíst stránky při přístupu), aplikace dostane SIGBUS. Tohle je podobná situace.

[petr_p]

Protože výpadek stránky se tradičně oznamuje přes SIGSEGV. SIGBUS spíše znamená problém při dolování dat z paměťového zařízení. O použití SIGBUS po mmap() jsem neměl tušení. Je pravda, že obě dává smysl.

[luky]

Semanticky dava smysl SIGBUS. SIGSEGV znamena, ze bylo pristoupeno na pamet, ktera nema mapovani. SIGBUS oznacuje spatny pristup k mapovane pameti. Jelikoz tento signal se bude posilat pro pamet, ke ktere bylo vytvoreno mapovani pomoci madvise, je semanticky spravne poslat signal SIGBUS!

[Sten]

SIGBUS může snadno nastat i na x86{,_64}, třeba když namapujete soubor z flash disku a před čtením jej vytáhnete. Přesný důvod signálu může signal handler přečíst ze siginfo, musí ale používat formát void handler(int, siginfo_t *, void *);.

[JZD]

Chybí odkaz na lwn.net od Willa Deacona.