Jaderné noviny - 14. 7. 2015: Tvorba pohyblivých stránek

7. 11. 2015 | Redakce | Jaderné noviny | 2733×

Jaderné noviny: Stav vydání jádra. Citáty týdne. Tvorba pohyblivých stránek.

Stav vydání jádra

Současný vývojový kernel nese označení 4.2-rc2. Uvolněn byl 12. července. Linus: „Nejedná se o nijak velké rc vydání, vše je relativně v klidu. Nějaké problémy jsme sice v -rc1 měli, ale nešlo o nic závažného, takže budeme doufat, že -rc2 bude mít méně otravných problémů.“

Stabilní aktualizace: 4.1.2, 4.0.8, 3.14.48 a 3.10.84 byly vydány 10. července. Verze 4.0.9, jakmile vyjde, bude poslední ze série 4.0.x.

Citáty týdne

Nedá mi to, abych trošku nezareptal – co jsme uvolnili 2fa, jen 30 lidí si zřídilo token (ani ne 10 % všech majitelů účtu) a jen 25 z celkového počtu 450 definovaných repozitářů/subdirs má 2fa požadavek."

-kernel.org manager Konstantin Ryabitsev

Ano, je skvělé, pokud dokážeme věci zachytit v -next. Ale nemyslím si, že by patche, které opravují chyby v Linusově stromu, měly čekat ve stromu next před přesunutím do Linusova stromu, protože tyto patche opravují chyby, které již ve stromu next byly, jen se na ně přišlo až v době přesunu do Linusova stromu. Proto si myslím, že je ztrátou času dávat je do next předtím, než je odešleme přímo Linusovi.

-Steven Rosted

Uvědomuji si, že současné sado-masochistické chybové zprávy ve stylu „Error, došlo k chybě, zavřít“ jsou v současném Linuxu jakýmsi statusem quo, jehož nepřehledné hlášení chyb pochází z rané technologické chyby unixového systémového volání, které pokazilo hlášení chyb. Taky vidím, že po letech zneužívání lidé vykazují jisté známky stockholmského syndromu spojeného s tímto problémem, ale ono to tak opravdu nemusí být...

-Ingo Molnar

Tvorba pohyblivých stránek jádra

Dlouhodobým aspektem subsystému řízení paměti je, že má po čase sklon fragmentovat paměť. Běží-li systém jistou dobu, může být vyhledání skupin fyzicky souvislých stránek obtížné, proto může kód jádra jít někdy až do krajnosti, aby se vyhnul souvislým blokům stránek. Někdy jsou ovšem velké bloky zapotřebí, vyžaduje je například funkce transparentních velkých stránek. Paměť je možné defragmentovat za pochodu s mechanismem pro shlukování paměti, ale shlukování může být snadno zmařeno stránkami alokovanými jádrem, které nelze jen tak přesunout bokem.

Stránky uživatelského prostoru lze přesouvat snadno, jsou přístupné skrze tabulky stránek, takže přesun stránky je otázkou změny příslušných položek tabulky stránek. Stránky v systémové mezipaměti stránek jsou také přístupné pomocí vyhledávání, takže je možné je také přesouvat. U stránek alokovaných náhodným subsystémem nebo ovladačem jádra to tak jednoduché není. Přímý přístup k nim umožňují ukazatele z jaderného prostoru a bez přesunu všech těchto ukazatelů se s nimi nedá hýbat. Vzhledem k tomu, že je velmi těžké přesouvat stránky jádra, snaží se subsystém řízení paměti oddělit tyto stránky od těch, které přesouvat lze, jenomže takové oddělení je těžké udržet hlavně v případě, kdy dochází k nedostatku paměti. Jediná „nepřesunutelná“ stránka může zmařit shluknutí (compaction) velkého bloku paměti.

Vyřešení tohoto problému v daném subsystému bude vyžadovat spolupráci toho daného subsystému v procesu komprimace; což je přesně to, co patch Gioha Kima pro migraci stránek dělá. Navazuje na speciální kód (představený již v roce 2012), který umožňuje přesouvání ballooningem řízených stránek, patch dokáže kód zobecnit, takže je využitelný i v jiných subsystémech.

Chcete-li, aby ovladač (nebo jiný subsystém jádra) podporoval migraci stránek (a tedy i shlukování), prvním krokem je alokování anonymního inode, který bude tyto stránky reprezentovat:

    #include <linux/anon_inodes.h>
    
    struct inode *anon_inode_new(void);

Jediným skutečným účelem tohoto inode je držet ukazatel na strukturu address_space_operations obsahující několik zpětných volání, která se týkají migrace. Příslušné metody:

    bool (*isolatepage) (struct page *page, isolate_mode_t mode);
    void (*putbackpage) (struct page *page);
    int (*migratepage) (struct address_space *space, struct page *page,
    			struct page *newpage, enum migrate_mode mode);

migratepage() je součástí jádra (v různých podobách) od verze 2.6.16, ostatní věci jsou nové a přináší je Giohův patch. Subsystém jádra musí poskytnout všechny tři operace, jinak není shlukování stránek možné. Jakmile dojde k alokování anonymního inode, jeho pole i_mapping->a_ops by mělo odkazovat ke struktuře address_space_operations, která obsahuje výše vypsané metody.

Asi není třeba zdůrazňovat, že v systému shlukování stránek jsou podporovány pouze celé stránky, paměť alokovaná ze slab cache zůstane nehybná. Aby bylo možné stránku přesunout kódem pro shluknutí, je zapotřebí, aby subsystém jádra (1) označil stránku jako „mobilní“ a (2) nastavil mapovací pole k anonymnímu inode:

    __SetPageMobile(page);
    page->mapping = anon_inode->mapping;

Jakmile je toto hotovo, může se jádro rozhodnout pro přesun stránky, pokud se ukáže, že je v cestě. Prvním krokem je volání isolatepage(), které odpojí vnitřní mapování a zajistí, že přesun stránky je skutečně možný. Argument mode není relevantní pro většinu kódu mimo subsystém správy paměti, funkce by měla vrátit true, jestliže je přesun stránky možný. Není nutné zastavit chod dané stránky, jde o to zachovat schopnost přesunu.

K migraci stránky může, ale nemusí dojít v závislosti na tom, zda jsou okolní stránky pohyblivé. Pokud k tomu dojde, může být vyvoláno zpětné volání migratepage(). Mělo by udělat cokoli, co je třeba k přesunu stránky, nastavit správně příznaky a aktualizovat všechny interní odkazy na novou stránku. Mělo by použít jakékoliv zámky nutné k tomu, aby se zabránilo souběžnému přístupu v době, kdy probíhá migrace. Návratový kód by v případě úspěšného přesunu měl být MIGRATEPAGE_SUCCESS, jinak se zobrazí chybová hláška. Pokud se migrace podaří, na starou stránku se po návratu migratepage() již nesahá.

Posledním krokem je volání putbackpage(). Má na starost nahradit danou stránku v jakýchkoli vnitřních seznamech a obecně dokončit proces migrace. Jestliže došlo k volání isolatepage(), dojde i na putbackpage() nehledě na to, zda mezi těmito voláními k migraci skutečně došlo.

Jak je vidět, k podpoře migrace na vybraném subsystému jádra je toho třeba docela dost udělat. Vzhledem k tomu to vypadá, že bude podpora omezena na relativně malý počet subsystémů, které využívají velké množství paměti. Giohův patch tímto způsobem adaptuje balloon driver na systémech, které využívají virtualizace, mohou balloon systémy (vzhledem ke své povaze) využívat velké množství paměti, takže možnost jejich přesunu dává smysl. Další případy využití zahrnují trvanlivé I/O buffery (grafické ovladače), které ukládají velké množství paměti. Oprava byť některých těchto ovladačů by měla pomoci při vzniku velkých, fyzicky sousedících oblastí volné paměti, a to i po delší době běhu systému.

       

Komentáře

[Radovan Garabik]

Memory compaction != kompresia (compression)

[|🇵🇸]

Shlukování paměti, dobrá poznámka.

[izidor]

chyba ve verzi, misto 2.16 tam ma byt 2.6.16

[|🇵🇸]

Díky; taky opraveno.

[J.]

Zajímalo by mě, proč se v Linuxu neprosadil systém chybových hlášení tak jak byl na starých UNIXech. Unikátní kód s popisem chyby někde v dokumentaci.

[Michal Kubeček]

Nenapadají mne žádné podstatné výhody, které by takové řešení mělo. Zato mne hned napadne několik nevýhod:

• výrazně horší čitelnost a přehlednost logu
• nutnost udržovat databázi chybových kódů aktuální
• potřeba řešit alokaci kódů pro out of tree moduly
• většina chybových hlášení má nějaké parametry

[Josef Kufner]

A co jen doplnit stávající hlášky o kódy a zdokumentovat? Alokaci kódů lze vyřešit vhodným tvarem kódu. Logy budou pořád stejně přehledné. Dokumentace se bude lépe hledat.

Ale asi bych jako hlavní překážku viděl obecnou lenost psát dokumentaci.

[J.]

Mě to napadlo v reakci na ten citát Ingo Molnara. Tak jako relevantní se mi zdají ty parametry, které by to asi zabily. Ostatní mi přijde snadno řešitelné. Mě by se na tom třeba líbilo pevná alokace paměti pro kód chyby přičemž vata by byla v separátním souboru. Možnost kompilace jádra pouze s kódy chyb, nebo včetně popisu. Samotný kód by nesl část informací. No nic, nejsem vývojář, takže asi plácám nesmysly.

[Josef Kufner]

No... ono log jen s kódy je docela otrava číst. Teoreticky by to mohla řešit čtečka, která by kódy interpretovala, ale když to je potřeba, obvykle ten stroj moc nefunguje.

Docela pěkně tohle řeší MySQL. Prostě z toho vypadne hláška "#1234: Spadlo ti to, bla bla.", ze které víš i bez slovníku, co znamená, a současně se to snadno hledá v dokumentaci a diskuzích. Navíc se ten kód dá dobře programově porovnávat (výjimka ho dostane jako číslo, není potřeba to parsovat), takže se snadno na takové chyby reaguje (např. pokud to chcíplo na unikátnost primárního klíče, tak je to ok, ale jinak spadni).

[Michal Kubeček]

Aha, myslel jsem, že je řeč o logu jádra. Ten citát naráží na to, jak syscall signalizuje chyby userspace, a to naopak funguje přesně tím způsobem, jaký jste navrhoval, tj. číselný kód z jakéhosi zdokumentovaného seznamu. Část problému je v tom, že ten seznam není moc bohatý a obecně není moc chuť ho rozšiřovat, část je právě v tom, že je tenhle model příliš omezující.

[J.]

Aha, to je zajímavé. Díky.