Portál AbcLinuxu, 21. května 2025 09:45
Jaderné noviny: Stav vydání jádra. Citáty týdne. Tvorba pohyblivých stránek.
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.
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.
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...
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.
7.11.2015 19:56
Fluttershy, yay! | skóre: 93
| blog:
8.11.2015 15:49
Fluttershy, yay! | skóre: 93
| blog:
Nenapadají mne žádné podstatné výhody, které by takové řešení mělo. Zato mne hned napadne několik nevýhod:
10.11.2015 19:10
Josef Kufner | skóre: 70
10.11.2015 19:51
Josef Kufner | skóre: 70
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.