Jaderné noviny – 5. 6. 2014: Lepší zamykání stránek v paměti

24. 6. 2014 | Luboš Doležel

Články - Jaderné noviny – 5. 6. 2014: Lepší zamykání stránek v paměti  

Aktuální verze jádra: 3.15-rc8. Začleňovací okno 3.16, část první. Zamykání a připevňování.

Obsah

• Aktuální verze jádra: 3.15-rc8
• Začleňovací okno 3.16, část první
• Zamykání a připevňování

Aktuální verze jádra: 3.15-rc8

Aktuální vývojová verze jádra je 3.15-rc8 vydaná 1. června. V tuto chvíli Linus otevřel začleňovací okno pro Linux 3.16. Chce se vyhnout tomu, aby bylo okno otevřené během jeho blížící se rodinné dovolené. Nuže uvidíme, jak dobře to půjde – poslední týdny vydání obvykle jen trávím čekáním, jestli se nestane něco zlého, takže takovéhle překrytí vývoje by *mělo* být v pohodě. Možná to bude fungovat tak dobře, že to budeme takhle dělat i v budoucnosti, i kdyby se mi to *nekrylo* s něčím jiným, kvůli čemuž bych měl potřebu otevírat začleňovací okno dřív, než jsem 100% připraven vydat předchozí verzi. Níže najdete přehled toho, co bylo zatím začleněno.

Stabilní aktualizace: verze 3.14.5 a 3.10.41 vyšly 31. května. Aktuálně se žádné stabilní aktualizace nerevidují.

Začleňovací okno 3.16, část první

Začleňovací okno cyklu 3.16 nám může posloužit jako pohled do budoucnosti, kdy bude jádro možná vycházet ještě častěji než dnes. Tím, že Linus otevřel okno pro 3.16 ještě před konečnou verzí 3.15, Linus možná zkrátil rozestup mezi vydáními o týden. Délka vývojových cyklů jádra se obecně snižuje, u posledních vydání šlo obecně o 60 až 70 dnů. I když se Linusův důvod pro překrytí vývojových cyklů – rodinná dovolená – nemusí v dohledné době opakovat, možná přijde na to, že mu podobná paralelizace vyhovuje.

Na rozdíl od předchozích začleňovacích oken teď Linus bude po dobu jednoho týdne pracovat se dvěma větvemi – nebo možná ještě déle, pokud se v -rc8 objeví závažné problémy. Máme tu hlavní řadu (tedy „master“), neboli větěv, kde se hromadí – doufejme jen malé – opravy, které míří do 3.15. Současně s tím spravuje větev „next“, kde se shromažďují změny pro 3.16 (neboli změny v začleňovacím okně). Po vydání 3.15 pravděpodobně sloučí next do masteru a bude dále začleňovat tam.

Jak Linus zmínil v oznámení vydání -rc8, tato část vývojového cyklu je pro něj a ostatní jaderné hackery docela nudná. Linus po dobu posledních několika týdnů obvykle jen čeká, jestli se něco nepokazí. Pokud tento „experiment“ zafunguje, jedno- nebo dokonce dvoutýdenní překrytí mezi jadernými cykly by se mohlo stát běžným postupem. To by mohlo už tak zběsilé tempo jaderného vývoje ještě více zrychlit.

V době psaní tohoto textu Torvalds přetáhnul 5348 neslučovacích změn pro Linux 3.16 (a 54 do hlavní řady po tagu v3.15-rc8). Jelikož se nacházíme v nezvyklé situaci, je trochu těžké odhadovat, kdy bude začleňovací okno uzavřeno, ale můžeme hádat, že se tak stane, než odjede na dovolenou, vydání -rc1 tedy můžeme očekávat okolo 15. června.

Mezi změny viditelné uživatelům patří:

• Xen na ARMu nyní podporuje uspávání a probouzení.
• Pro So Marvell Armada 375 a 38x byla zařazena podpora pro SMP. Ta byla navíc přepracována pro  Allwinner A31.
• Virtuální platforma Goldfish nyní podporuje 64 bitů.
• Raný ladící výstup na konzoli byl zobecněn a byla přidána podpora pro ranou konzoli na sériovém portu p1011.
• KVM se na s390 dočkalo optimalizací, podpory pro migraci a podpory GDB.
• KVM má počáteční podporu pro little endian na POWER8. V rámci projektu se pracovalo i na rozhraní pro uživatelský prostor na MIPS, virtualizovaném časovači a vnořených plně virtualizovaných hostech na x86.
• ACPI video nyní bude standardně používat nativní ovladače podsvícení namísto rozhraní podsvícení ACPI, což by mělo obecně pomoci na systémech s rozbitými BIOSy pro Win8, jak říká Rafael Wysocki v žádosti o přetažení.
• Podpora nového hardwaru.

Mezi změny viditelné vývojářům jádra patří:

• Architektura m68k má nyní podporu early_printk() pro více platforem.
• V subsystému GPIO proběhlo velké pročištění a refaktorování.
• Bylo odvedeno mnoho práce na blokové vrstvě o vícero frontách; v 3.16 bude funkčností a výkonem dokončené blk-mq, řekl Jens Axboe v žádosti o přetažení. SCSI o více frontách se objeví v 3.17. Na více front byl převeden i ovladač Micron PCIe a tyto změny byly rovněž začleněny.
• Několik souborů blokové vrstvy bylo přesunuto z adresářů fs/ a mm/ do adresáře block/: bio.c, bio-integrity.c, bounce.c a ioprio.c.
• Samsung Exynos ARM SoC nyní podporují víceclusterovou správu výkonu, což umožňuje přepínání CPU big.LITTLE. Objevila se také podpora pro víceplatformní jádra, ale ještě se musí zapracovat na ovladačích.
• CONFIG_USB_DEBUG bylo odstraněno a všechny USB ovladače byly převedeny na používání dynamického rozhraní pro ladění.
• Skupina funkcí pro paměťové bariéry smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}() byla zredukována na pouhé dvě: smp_mb__{before,after}_atomic().

Příště se podíváme na změny přetažené po tomto souhrnu. Jesliže se objeví zásadní změny i poté, tak je probereme ještě následující týden.

Zamykání a připevňování

Jádro už dlouho podporuje uzamykání stránek do fyzické paměti; jedním ze způsobů, jak toho dosáhnout, je systémové volání mlock(). Ukazuje se ale, že je více způsobů, jak udržet paměť na místě, přičemž některé způsoby se chovají jinak než jiné. Výsledkem je zmatek v účtování prostředků a ne zcela optimální chování správy paměti na aktuálních jádrech. Patch od Petera Zijlstry to může brzy napravit formalizováním druhého typu zamykání stránek pod názvem „připevňování“ (pinning).

Jedním z problémů se zamykáním paměti je to, že nesplňuje požadavky všech uživatelů. Stránka, která byla v paměti uzamčena pomocí volání jako mlock(), musí vždy být fyzicky přítomna v systémové RAM. Při přístupu k uzamčeným stránkám by tedy zjednodušeně nemělo nikdy dojít k výpadku stránky. Nic ale nevyžaduje, aby uzamčená stránka byla vždy na tom samém místě; jádro může uzamčenou stránku libovolně přesouvat. Migrace stránky vyvolá malý [soft] výpadek stránky (který je vyřešen bez I/O) při přístím přístupu ke stránce. Povětšinou to není problém, ale vývojáři těžce realtime aplikací vyvíjejí mnoho úsilí, aby se vyhli sebemenší latenci způsobené malým výpadkem. Tito vývojáři by rádi viděli ještě přísnější zamykání, které zaručuje, že k výpadku nedojde nikdy. Jádro aktuálně takovou úroveň zamykání paměti neposkytuje.

Zamykání také nesplňuje potřeby různých uživatelů v rámci jádra. Zejména pak kód jádra, který používá rozsah paměti jako buffer DMA, potřebuje mít jistotu, že daná paměť nebude přesunuta. Kvůli tomu nebyl mechanismus zamykání pro tyto stránky nikdy používán; místo toho jsou drženy na místě pomocí inkrementování jejich čítače referencí nebo přes volání get_user_pages(). Takové stránky jsou ve výsledku drženy na místě, ale jádro nemá jak vědět, že mohou být drženy po dlouhou dobu.

Tyto neformálně zamčené stránky nás vedou k jedné otázce: jaká je jejich interakce s mechanismem omezování prostředků? Jádro administrátorovi umožňuje shora omezit, kolik stránek může uživatel uzamknout do paměti. Ale v některých případech je vytvoření DMA bufferu sdíleného s uživatelským prostorem výsledkem žádosti aplikace. Takže uživatelé mohou uzamykat stránky v paměti pomocí operací jako vytvoření vzdálených DMA (RDMA) bufferů; tyto stránky se v současnosti nepočítají nezohledňují při vynucování maxima uzamčených stránek. To vadí administrátorům a vývojářům, kteří chtějí, aby se omezení uzamčených stránek vztahovalo na všechny uzamčené stránky, ne jen na vybrané z nich.

Tyto „skryté“ uzamčené stránky vedou ještě k dalšímu problému. Obvykle se subsystém správy paměti snaží oddělit přesunutelné stránky od nepřesunutelných. Ale v tomto případě jsou stránky často alokovány jako běžná anonymní paměť – jinými slovy jako přesunutelné stránky. Jejich uzamčení na jejich místě je pak činí nepřesunutelnými. Kvůli tomu pak překáží, jakmile se kód pro správu paměti snaží vytvořit souvislé rozsahy paměti přesouváním stránek; jsou v oblasti vyhrazené pro přesunutelné stránky, ale jelikož jsou nepřesunutelné, není možné je přemístit tak, aby bylo možné vytvářet větší souvislé bloky.

Peterův patch se všechny tyto problémy snaží vyřešit – nebo alespoň ukazuje, jak se mají řešit. Vytváří formální definici „připevněné“ [pinned] stránky, která musí zůstat na svém fyzickém umístění. Připevnění stránky se drží v oddělené oblasti virtuální paměti (VMA), která je označená příznakem VM_PINNED. V rámci jádra je možné stránky připevnit novou funkcí mm_mpin():

int mm_mpin(unsigned long start, size_t len);

Tato funkce připevní stránky v paměti, ale jen pokud to omezení prostředků volajícího procesu umožňují. Jaderný kód, který potřebuje k připevněné paměti přistupovat přímo, bude samozřejmě stále muset volat get_user_pages(); toto volání by se mělo udělat po mm_mpin().

Jedním z dlouhodobějších cílů (který není součástí tohoto patche) je učinit funkčnost připevňování stránek přístupnou uživatelskému prostoru. Nové systémové volání mpin() by fungovalo jako mlock(), akorát by mělo dodatečnou záruku, že stránka nebude nikdy přesunuta, a tedy při přístupu k ní nedojde k výpadku. Přidání této funkčnosti by asi bylo jen otázkou přidání volání jako takového.

Další aktuálně neimplementovanou funkcí je migrace stránek před jejich připevněním. Volání mm_mpin() říká, že dotyčné stránky nebudou v blízké budoucnosti přesunuty. Proto by dávalo smysl, aby je jádro přesunulo z přesouvatelné zóny (pokud se právě tam zrovna nachází) do jednoho z rozsahů určených pro nepřesunutelné stránky. To by zabránilo připevněným stránkám v tom, aby překážely při kompakci paměti, a tudíž by to usnadnilo vytváření větších bloků volné paměti na původním místě těchto stránek.

A na závěr, umisťování připevněných stránek do jejich vlastního VMA docela usnadňuje jejich sledování. Takže je možné připevněné stránky započítávat do limitu uzamčených stránek, čímž se uzavírá tato konkrétní skulina.

Zatím tento patch nikoho moc nezajímal. Během dřívějších debat byly vyjádřeny obavy, že změnění počítání uzamčených stránek by mohlo vyvolat regrese na systémech, kde se uživatelé blíží k limitům. Tento problém se dá obejít různými způsoby; buď bychom připevněné stránky do tohoto limitu nepočítali nebo bychom pro ně mohli vytvořit oddělený limit. Ani jedna varianta není zrovna přitažlivá, proto je možné, že tento patch projde tak, jak je.

Diskuse k tomuto článku

[jhquentin]

nerozumim, kdyz dneska uz je venku jadro 3.15.1 - stable a 3.16-RC2, proc je tu 3.15RC8.

Diky

[chrono]

Názov článku je "Jaderné noviny – 5. 6. 2014: Lepší zamykání stránek v pamět"

[ebik]

http://www.abclinuxu.cz/clanky/jaderne-noviny-3.-4.-2014-diskove-bloky-vetsi-nez-4k/diskuse#11

Hmm, nemela by tato informace byt na konci kazdeho clanku serialu? Posledni dobou se na to pod kazdym dilem nekdo pta...

[stativ]

To by stejně nejspíš nepomohlo. I kdyby se to před odesláním komentáře zobrazilo velkým červeným písmem a vyžadovalo potvrzení, že to uživatel přečetl, tak by se tenhle dotaz objevil. Řekl bych, že to už tak nějak patří ke zdejšímu folklóru.

[jekub]

Dotaz nově přišedšího, v zápětí zopovězen. A hned se v tom budeme patlat.

Řekl bych, že to už tak nějak patří ke zdejšímu folklóru.

[Michal Kubeček]

Představte si, že existují i lidé, kteří čtou všechny díly. A když pod každým druhým nebo třetím čtou pořád stejné komentáře, někdy udivené, někdy kousavě ironické, tak jim to už leze na nervy. Tím spíš, že i "nově přišedší" by si snad mohl všimnout data v nadpisu nebo se zkusit trochu zamyslet.

[jekub]

Představovat si nic nepotřebuji, jednoho takového znám osobně a párkrát mě také svrběly prsty

Všimnout si zajisté mohl, ale nevšiml. Vysvětlení se mu dostalo do chrona, proč se v tom dál patlat?

Ja vím, je to těžké. Ale přesto...

[frr]

Zas... je hezké, že se tu občas objeví mladá krev Vídat v těch debatách 12 let tytéž lidi by trochu zavánělo uzavřeným klubem pro důchodce, se sdílenou specifickou zálibou... Kromě toho už by dávno nebylo o čem flejmovat.

[frr]

mohli bychom to třeba považovat za hezký zasvěcovací rituál...

[Honz]

Něco jako "Tímto tě pasuji na hlupáka. Nyní si polib šos a umísti si na tvář tuto dlaň."