Jaderné noviny – 19. 6. 2014: Nejistý osud volatilních rozsahů

8. 7. 2014 | Luboš Doležel | Jaderné noviny | 3822×

Aktuální verze jádra: 3.16-rc1. Citáty týdne: Paul McKenney. Začleňovací okno 3.16 se završuje. Volatilní patch pro volatilní rozsahy.

Obsah

• Aktuální verze jádra: 3.16-rc1
• Citáty týdne: Paul McKenney
• Začleňovací okno 3.16 se završuje
• Volatilní patch pro volatilní rozsahy

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

Aktuální vývojová verze jádra je 3.16-rc1 vydaná 15. června. Linus k ní řekl:

Možná to bylo trochu neobvyklé dvoutýdenní začleňovací okno, a to kvůli tomu, že máme jen týden od vydání verze 3.15 a první týden se překrýval s posledním -rc pro předchozí vydání, ale nezdá se, že by to mělo na vývoj dopad. Věci se zdají být normální a když už, tak jde o jedno z větších začleňovacích oken spíš, než že by patřilo mezi ta menší. Není tak veliké jako okno pro 3.15, ale nemá k němu tak daleko.

Nakonec bylo přetaženo celkem 11 364 sad změn (3.15-rc1 jich mělo 12 034).

Stabilní aktualizace: verze 3.15.1, 3.14.8, 3.10.44 a 3.4.94 všechny vyšly 16. června. Výčet oprav je tentokrát docela krátký, ale i tak stojí za to je mít.

Citáty týdne: Paul McKenney

V mé hlavě se nachází jakási impresionistická malba RCU. A v jednom z rohů je něco, co by mohl být pes. Pokud je to opravdu pes nebo to můžeme přesvědčit, aby se to jím stalo, pak by možná mohl vést stádo ovcí uprostřed malby. Přinejmenším vypadají jako ovce. Možná to jsou deštivá oblaka. Nebo napudrovaní advokáti s parukami. V takovém případě by zajisté stálo za to je jen pro pobavení seznámit se zmiňovaným psem.

Nuže, mám namířeno do posilovny. Několik návštěv posilovny a spánkových cyklů tuto malbu možná přetvoří na užitečný kód. Tento přístup mi za uplynulá léta mnohokrát zafungoval, tak je jistá naděje, že to tak opět dopadne.

-- Škola návrhu softwaru Paula McKenneyho

Začleňovací okno 3.16 se završuje

15. června Linus Torvalds vydal předverzi 3.16-rc1 a ukončil začleňovací okno tohoto cyklu. Od nynějška by se neměly přidávat nové funkce, půjde hlavně o opravy a stabilizující patche.

Torvalds do verze 3.16 začlenil 11 364 neslučovacích změn. Od přehledu z minulého týdne jde o 3200 změn (a celkem o téměř 6000 od prvního přehledu). Poslední dvě začleňovací okna jsou v trojici největších začleňovacích oken co se commitů týče, 3.16 je na třetím místě za 3.10 (11 963) a 3.15 (12 034). Uvidíme, zda tento trend bude pokračovat a dočkáme se u 3.17 a dalších verzí 11 až 12 tisíc patchů.

Tak jako tak tu máme přehled významných změn, které uživatelé ve verzi 3.16 uvidí:

• Moduly nyní mají bity jen ke čtení (RO) a pro zákaz spouštění (NX) nastaveny mnohem dříve v průběhu načítání, ještě než jsou zpracovány argumenty modulů. Toto ještě více omezí časový úsek, během kterého by špatně se chovající (nebo zákeřný) modul mohl upravit nebo spustit svá data.
• BPF filtry pro bezpečné výpočty (seccomp) jsou nyní kompilovány v režimu JIT.
• Byla přidána podpora pro TCP fast open na IPv6.
• Virtuální síťová rozhraní Xen mají nyní podporu pro vícero front, což vede k mnohem lepšímu výkonu.
• Byla přidána podpora pro aktivní čekání (busy polling) na soketech SCTP. Funkce se na soketu aktivuje pomocí volby SO_BUSY_POLL; může snížit latenci při čtení na rozhraních s vysokým provozem, která tuto volbu podporují.
• Modul pro rozšířené ověřování (EVM) má konfigurační volby přidávající podporu vkládání nových rozšířených atributů (xattrs) do výpočtu HMAC pro soubor. Díky této funkčnosti mohou být tři atributy Smacku (SMACK64EXEC, SMACK64TRANSMUTE a SMACK64MMAP) přidány do výpočtu HMAC.
• Btrfs má nové ioctl() nazvané BTRFS_IOC_TREE_SEARCH_V2, se kterým lze hledat klíče na systému souborů. Jak z názvu vyplývá, jde o flexibilnější verzi BTRFS_IOC_TREE_SEARCH, se kterou lze předávat větší buffer pro získávání větších výsledků vyhledávání, které by se nevešly do bufferu o pevné velikosti 3992 bajtů.
• Podpora nového hardwaru.

Mezi změny zajímavé pro vývojáře jádra patří:

• V lib/interval_tree.c najdete jednoduché rozhraní intervalového stromu. Intervalový strom je implementován jako rozšířený RB strom.
• Sledovací body mají přesnější rozlišení událostí v průběhu uspávání a probouzení.
• Interpretr BPF má nyní testy sebe sama, které pokrývají jak klasické tak interní instrukce BPF.
• Přibylo API pro TCP TSO (segmentation offload); několik ovladačů (mvneta, mv643xx_eth apod.) jej používá pro přidání softwarové podpory TSO.
• Soubor Documentation/mutex-design.txt byl značně zaktualizován, takže více odpovídá skutečnosti.
• Byl přidán optimistický spinning do read-write semaforů (rwsems). Přibyla rovněž frontová varianta RW zámků (qrwlocks).
• Ve struct file_operations přibyly dvě nové metody read_iter() a write_iter(). Smyslem je podporovat přechod na rozhraní iov_iter, které nakonec nahradí metody aio_read() a aio_write().

Nyní začíná stabilizační fáze verze 3.16. To znamená, že se vydání konečné verze 3.16 dočkáme někdy začátkem srpna v závislosti na tom, jak bude cyklus probíhat. Pak přijde čas na to zopakovat si to zase s verzí 3.17.

Volatilní patch pro volatilní rozsahy

"Volatilní rozsah" je název, kterým označujeme oblasti paměti v uživatelském prostoru, které může jádro uvolnit, je-li paměti málo. Typickým případem použití je cache obrázků ve webovém prohlížeči; prohlížeč by si rád uchoval tyto informace v paměti pro rychlejší načítání stránek, ale obejde se i bez nich, pokud by paměť použitá pro cache byla zapotřebí jinde. Implementace volatilních rozsahů se dočkaly neobvykle velkých změn; to bude dost možná pokračovat dál – pokud se najde vývojář, který by v práci pokračoval.

Rané verze patche byly založené na systémovém volání posix_fadvise(). Někteří vývojáři si stěžovali, že jde spíše o koncept související s alokací, takže byl patch přepracován tak, aby se používalo fallocate(). Do konce roku 2013 se plán změnil – přibyla dvě nová systémová volání nazvaná fvrange() a mvrange(). 11. verze vydaná v březnu 2014 přechází na jediné systémové volání nazvané vrange(). Během všech těchto iterací se objevily také obavy o sémantiku v uživatelském prostoru (hlavně tedy co se stane, pokud se proces pokusí přistoupit ke stránce, která byla uvolněna) a nejlepší interní způsob implementace volatilních rozsahů. Takže nebylo zatím do jádra začleněno nic.

14. verze, kterou 29. dubna zaslal John Stultz, opět mění API v uživatelském prostoru. Volatilní rozsahy nyní používají systémové volání madvise(). Zejména pak volání:

madvise(address, length, MADV_VOLATILE);

označí oblast paměti o length bajtech začínajících na address jako volatilní. Jakmile je oblast takto označena, jádro může s ní spojené stránky kdykoliv uvolnit a jejich obsah zahodit. Pokud aplikace potřebuje k oblasti přistoupit v budoucnosti, měla by oblast označit jako nevolatilní voláním:

madvise(address, length, MADV_NONVOLATILE);

Návratová hodnota nula značí úspěch (oblast je nyní nevolailní a předchozí obsah zůstal nedotčen), záporné číslo značí buď chybu, nebo úspěch v případě, že alespoň jedna stránka v rozsahu byla zahozena.

Používání madvise() už bylo v minulosti zvažováno; dává to smysl vzhledem k tomu, že cílem je jádru dát doporučení ohledně důležitosti určité oblasti paměti. Předchozí implementace volatilních rozsahů měly ale tu vlastnost, že označování oblasti jako nevolatilní mohlo na půli cesty selhat. To znamenalo, že rozhraní muselo mít schopnost vrátit dvě hodnoty: 1) kolik stránek bylo úspěšně označeno a 2) zda některé z nich byly zahozeny. Tentokrát ale John našel způsob, jak učinit tuto operaci atomickou v tom smyslu, že buď celá uspěje, nebo selže. Jelikož tedy druhá návratová hodnota už není potřeba, rozhraní madvise() je pro tento účel vhodné.

Co se stane, když se uživatelský prostor pokusí přistoupit k volatilní stránce, jež byla mezitím zahozena? Tato implementace doručí signál SIGBUS. Náležitě připravená aplikace může tento signál zpracovat a získat data z jiného zdroje; nepřipravené aplikace místo toho po sobě zanechají nepořádek v podobě core dumpu. To možná nevypadá jako přátelské chování, ale mohli bychom tvrdit, že by aplikace neměla přímo přistupovat k paměti, kterou podle instrukcí, jež dala jádru, nutně nepotřebuje.

Minchanu Kimovi se tento přístup nelíbí; dal by přednost tomu, aby aplikace zkrátka obdržela v takové situaci novou stránku plnou nul. Uvažuje totiž o jiném případu užití: jde mu o kód, který opětovně používá paměť a říká jádru, že původní obsah není třeba zachovávat. V tomto případě by opětovné použití mělo mít co nejnižší režii; Minchanovi by více vyhovovalo, kdyby nebylo nutné používat MADV_NONVOLATILE nebo obsluhu signálu SIGBUS. John navrhl, že Minchanův vlastní patch MADV_FREE se pro tento případ hodil více, ale Minchan nesouhlasil, že prý MADV_FREE je jednorázová operace, zatímco MADV_VOLATILE se u rozsahu paměti zachovává napříč několika cykly zahození a opětovného použití. John má nicméně obavy, že tiché nahrazení stránek nulami by mohlo vést k poškození dat nebo jiným nepříjemným překvapením.

Johannes Weiner, který se do debaty zapojil v červnu, rovněž dává přednost tomu, aby zahozené stránky byly nahrazeny nulami při přístupu k nim. Zeptal se, zda by bylo patch možné přepracovat tak, aby pracoval nad MADV_FREE (které má podle něj lepší vnitřní implementaci) s cílem dát uživateli na výběr: aplikace by si mohly zažádat buď o prázdnou stránku, nebo o SIGBUS. John odpověděl, že to možná někdy zkusí:

Uvidím, jestli na to budu mít čas. Spíš je ale pravděpodobné, že budu muset uznat porážku a nechat to na někoho jiného. Zdá se, že opět opadl zájem i aktivita v podobě revidování a přibývá další práce, takže si nejsem jistý, zda dokáži ospravedlnit další práci na toto téma.

Johna určitě nemůžeme vinit z nedostatečného úsilí; patch od roku 2011 prošel čtrnácti revizemi; mluvilo se o něm i na Jaderném sumitu a Sumitu o úložištích, systémech souborů a správě paměti. Po připomínkách od různých lidí se dočkal rozsáhlých úprav. I tak to ale vypadá, že i když na zařazení funkce čekají skuteční uživatelé, tak nemá k zařazení do hlavní řady blíže.

Stejně tak je těžké něco dávat za vinu těm, kteří kód revidovali. Koncept volatilních rozsahů přidává nové chování správy paměti s různými drobnými detaily. Pokud implementace a rozhraní nebudou správně udělány, pak to vývojáře v jádře i mimo něj bude trápit po dlouhou dobu. Změny ve správě paměti se do jádra těžko dostávají z dobrého důvodu; stejně tak změny viditelné uživatelům. Tento patch se dotýká obou oblastí, kde – jak nás minulost už naučila – je obtížné udělat věci správně, proto je nezbytné si dávat pozor.

I tak si ale nemusíme být jisti tím, jestli je nezačlenění ničeho z dlouhodobého hlediska správnou cestou. Uživatelé začnou používat řešení vyvinutá mimo hlavní řadu jádra (zejména pak androidí „ashmem“), nad kterými nemá komunita takovou kontrolu. Pokud někdo nebude mít čas pokračovat v práci na tomto patchi, pak se této funkce nemusíme v jádře nikdy dočkat, což by uživatele nechalo bez funkčnosti, kterou jednoznačně vyžadují.

       

Komentáře

[Karry]

Existuje zpusob jak muze dat kernel aplikacim vedet ze by bylo vhodne zahodit pamet kterou nutne nepotrebuji? Vim ze se tento problem jiz nekolikrat resil, nevim ale jestli to dospelo k nejakemu vysledku... Dokazu si predstavit dany usecase bez volatile rozsahu...

[tap]

Toto by bolo oveľa horšie riešenie. Kernel v danom čase vie koľko potrebuje pamäte keď má zoznamy potenciálne voľnej vie sa nejak rozhodnúť. Keď kernel pamäť potrebuje napr. pre dáta ktoré na neho padajú zo siete nemôže si dovoliť poprosiť user space proces nech mu niečo láskavo dá. A potom ako dlho by mal kernel čakať kým user space procesy mu niečo uvolnia. Implementácia typu kernel pošle každému user space procesu signál. Je skoro isté že ako reakcia to bude pokračovať tak že väčšina procesov si nejakú pamäť vyžiada.

[Gilhad]

Kdyzi jsem o tom premyslel a dosel k nazoru, ze by mozna stalo za to, kdyby kernel (nebo nekdo jiny, zodpovedny) poslal zpravu ve chvili, kdy zbyva treba jen 10% pameti (nebo jina nastavitelna hodnota, nebo urcity pocet megabajtu, nebo tak neco), ve smyslu "kdyz to pujde takhle dal, zacnu radit a zahazovat pamet/volat OOMKillera, nechcete se dobrovolne zbavit neceho nepotrebneho?"

S tim, ze procesy bud uvolni nejakou pamet, nebo ji prestanou pozirat, nebo bude za chvili zle a nikdo se jich uz ptat nebude.

[Karry]

Naprosto souhlasím. Řešení čistě v Kernelu je hezčí. Ale já hledám řešení které by fungovalo na současném kernelu. Dokážu si představit že signál o tlaku na paměť by se posílal s dostatečným předstihem. Stále mi to přijde jako lepší řešení než v aplikaci pollovat /proc/vmstat

[tap]

Nejaké pokusy už zjavne boli http://lwn.net/Articles/268732/ http://lwn.net/Articles/475791/ V Chormiu to snáď majú zamergeované.

[luky]

Existuje zpusob jak muze dat kernel aplikacim vedet ze by bylo vhodne zahodit pamet kterou nutne nepotrebuji? Vim ze se tento problem jiz nekolikrat resil, nevim ale jestli to dospelo k nejakemu vysledku... Dokazu si predstavit dany usecase bez volatile rozsahu...

Jo, to muzete udelat normalne pres munmap()