Portál AbcLinuxu, 9. května 2024 17:06
Aktuální verze jádra: 3.0-rc3. Citáty týdne: pageexec, Linus Torvalds, Greg-Kroah Hartman. Nativní nástroj pro KVM v Linuxu v2. Debata o overlayfs. Přepracovaný alokátor spojité paměti.
Současné vývojové jádro je 3.0-rc3 vydané 13. června. Linus říká: Je tu spousta jednořádků, ale i větší kousky: aktualizace DRI pro Radeon, nějaké aktualizace btrfs a oprava podpory Sparc LEON (a podpora PCI). Menší aktualizace nilfs2 a ceph a s390 a arm. Krom toho jsou to většinou náhodné úpravy ovladačů všude možně. Zkrácený changelog je v oznámení, detaily najdete v kompletním changelogu.
Během tohoto týdne nevyšly žádné stabilní aktualizace. Aktualizace 2.6.32.42, 2.6.33.15 a 2.6.39.2 se v době psaní tohoto článku revidují; lze je očekávat 18. června nebo poté.
-- pageexec
-- Linus Torvalds se připravuje na 3.0.0
-- Greg-Kroah Hartman posouvá problémy na východní polokouli.
Druhá verze Nativního nástroje pro KVM v Linuxu (náhrada za QEMU) byla zaslána. Nástroj nyní obsahuje podporu grafiky, SMP, síťování, I/O se soubory je údajně rychlejší než v QEMU atd. „Oficiálním cílem“ vývojářů je nyní začlenění do vývojového cyklu jádra 3.1.
napsal Jonathan Corbet, 15. června 2011
Sjednocující souborové systémy umožňují zkombinovat několik souborových systémů a zpřístupnit je uživateli jako jediný strom. Při typickém použití zapisovatelný souborový systém překrývá základ, který je pouze pro čtení, což vytváří iluzi, že všechny soubory v daném souborovém systému lze změnit. Tento způsob práce je užitečný pro Live CD, embedded systémy, kde je potřeba rychlý reset do továrního nastavení, virtualizované systémy vybudované nad společným základním souborovým systémem a tak dál. Přestože by tato vlastnost byla užitečná, Linux nikdy neobsahoval sjednocující souborový systém, i když několik pokusů nějaký vytvořit tu bylo. Nedávný pokus situaci změnit možná uspěje, možná ne.
Jaderné noviny se souborovým systémem overlayfs zabývaly loni. Autorem overlayfs je Miklos Szeredi a souborový systém jako takový se odlišuje od jiných svou relativní jednoduchostí. Nedávno se Miklos zeptal, jestli by bylo možné začlenění do vývojového cyklu 3.1. Možná se mu toto přání splní, ale nejprve bude potřeba vyřešit nějaké problémy.
Andrew Morton přišel s několika připomínkami; jednou z nich je, že by problém mohlo být lepší vyřešit v uživatelském prostoru. Jednoduchost overlayfs přešel s tím, že Nezačlenit to vůbec je ještě menší a jednodušší, a navrhl, že by problémy s výkonností měly být řešeny zrychlením implementace v uživatelském prostoru. Linus nicméně tento aspekt debaty ukončil tím, že řekl: Lidí, kteří si myslí, že souborové systémy v uživatelském prostoru jsou dobré k něčemu jinému než k hraní si, jsou jednoduše pomatení. Implementace sjednocujícího souborového systému v jádře má tedy podle všeho cestu volnou.
Další Andrewova obava se týká toho, že overlayfs nemusí být dostatečné řešení:
Reagovat na tuto námitku je těžší. Bylo poukázáno na to, že OpenWRT overlayfs s klidem používá a Ubuntu to zvažuje. Jediný možná použitelný alternativní projekt jsou sjednocená připojení [union mounts], kterým se ale v nedávné době moc pozornosti nedostalo. Co se vlastností týče, nezdá se, že by v blízké budoucnosti přišlo něco dalšího, co by overlayfs zastínilo.
Co se technické stránky týče, sjednocující souborové systémy vždy přinášely nějaké unikátní problémy. Valerie Aurora, která v této oblasti odvedla dost práce, se na overlayfs dívala v červnu a zdá se, že se jí líbil:
V současné diskuzi lehce změnila tón a naznačila, že jsou zde nějaké těžkosti, které je potřeba vyřešit:
Také měla nějaké námitky ohledně zamykání, na což Miklos detailně zareagoval; námitky ohledně změn nižších souborových systému nicméně řešeny nebyly. Je tedy možné, že záležitosti s technickou korektností mohou zbrzdit začlenění overlayfs do jádra. Je zjevné, že po této vlastnosti je poptávka a že overlayfs je schopen ji hezky pokrýt – přijde čas, kdy bude jeho zdržování mimo jádro příliš těžké ospravedlnit.
napsal Jonathan Corbet, 14. června 2011
Problém spojený s alokací velkých kusů fyzicky spojité paměti je zde diskutován často. Povaha virtuální paměti je taková, že často rozhází stránky v systému; jádro ani nemusí běžet dlouho na to, aby byly relativně vzácné sousedící stránky. Mnoho let se s tímto problémem vývojáři jádra vyrovnávali tím, že se vyhýbali závislosti na velkých spojitých alokacích všude, kde to bylo možné. Jaderný kód, který se pokouší alokovat více než dvě fyzický spojité stránky, je výjimkou.
V nedávné době ale potřeba spojitých alokací začala růst. Jedním zdrojem poptávky jsou velké stránky [huge pages] a vlastnost transparentních velkých stránek konkrétně. Dalším je starý příběh s novým zvratem: hardware, který není schopen používat DMA rozsypej/sesbírej [scatter/gather]. Každé zařízení, které umí DMA pouze s fyzicky spojitou oblastí, vyžaduje (pokud není přítomna jednotka pro správu I/O paměti) k práci spojitý buffer. Tento požadavek je často příznakem low-endového (hloupého) hardware; můžeme jenom doufat, že takový hardware bude postupem času výjimkou. Co ale vidíme v současnosti, jsou čím dál schopnější zařízení, která si požadavek na spojitou paměť pro DMA ponechala. Příkladem jsou zachycovací jednotky, které dokáží vyprodukovat data ve vysokém rozlišení, provést s nimi několik transformací, ale pro uložení výsledku stále potřebují spojitý buffer. Příchod videa ve vysokém rozlišení problém zhoršuje – ty fyzicky spojité buffery jsou nyní o dost větší a alokují se hůře než dříve.
Téměř před rokem se Jaderné noviny zabývaly patchi pro alokátor spojité paměti [contiguous memory allocator, CMA], které měly problém vyřešit. Sada patchů následovala starou tradici rezervace kusu paměti při bootu jenom kvůli tomu, aby se vyhovělo požadavkům na velké alokace. Postupem let tuto techniku používal patch „bigphysarea“ i jednoduché bootování s parametrem mem=, který zajistil, že se kus paměti ponechal volný. Ovladač pmem z Androidu, který je mimo strom, také alokuje paměť z rezervované oblasti. Tento přístup rozhodně funguje; téměř 20 let zkušeností to potvrzuje. Nevýhodou je, že rezervovaná paměť se nedá použít jinak; pokud ji žádné zařízení nevyužívá, prostě nečinně sedí. U jaderných vývojářů – a uživatelů – bývá takové plýtvání poměrně nepopulární.
Z tohoto důvodu nebyly patche CMA nikdy začleněny. Problém ale nezmizel a nezmizeli ani vývojáři, kteří ho řeší. Nejnovější sada patchů CMA vypadá úplně jinak; i když je stále potřeba vyřešit nějaké záležitosti, má tato sada na první pohled mnohem lepší šance dostat se do hlavní řady.
Alokátor CMA stále může pracovat s rezervovanou oblastí paměti, ale rozhodně to není zamýšlený způsob fungování. Místo toho se CMA pokouší udržovat oblasti, ze kterých by bylo možné alokovat velké kusy spojité paměti, když to bude potřeba. Za tímto účelem se CMA hodně opírá o mechanismus „migrace typu“ [migration type], který je zabudován hluboko do kódu správy paměti.
V každé zóně jsou označeny bloky, které se mají používat pro stránky, které nejsou přesunutelné a které nelze zabrat [reclaim]. Přesunutelné stránky jsou hlavně cache stránek a anonymní stránky; přistupuje se k nim přes tabulky stránek a radix strom cache stránek. Jejich obsah lze přesunout jinam, pokud budou změněny i odpovídající tabulky a strom. Zabratelné stránky by mělo být možné vrátit jádru, když je to potřeba; obsahují datové struktury jako cache inodů. Nepřesunutelné stránky jsou obvykle ty, na které má jádro přímé ukazatele; například paměť získanou pomocí kmalloc() normálně nejde přesunout, aniž by se něco rozbilo.
Subsystém správy paměti se pokouší držet přesunutelné stránky pohromadě. Pokud je cílem uvolnit velký kus paměti tak, že se stránky odstěhují jinam, jediná přibitá stránka stačí k tomu, aby tato snaha přišla vniveč. Tím, že se přesunutelné stránky shlukují, jádro doufá, že bude schopné uvolnit na vyžádání velké rozsahy, aniž by se narazilo na nějaký háček. Kód shlukování paměti spoléhá na to, že takové rozsahy budou existovat, jinak by nemohl dělat svoji práci.
CMA tento mechanismus rozšiřuje přidáním nového typu migrace „CMA“; ten funguje podobně jako typ „přesunutelné“ [movable], ale s několika rozdíly. Typ „CMA“ je pevný; u stránek, které jsou takto označeny, by jádro nikdy nemělo změnit typ. Alokátor paměti nikdy v této oblasti nealokuje nepřesunutelné stránky; co se jiného použití týče, CMA stránky se alokují jenom, když není jiná možnost. Se štěstím by tedy oblasti paměti označené pro používání CMA měly obsahovat jenom přesunutelné stránky a měly by mít relativně velký podíl volných stránek.
Jinými slovy je takto označená paměť k dispozici zbytku systému za podmínky, že může obsahovat pouze přesunutelné stránky. Když přijde ovladač a žádá o spojitou oblast paměti, CMA alokátor se obrátí na jednu ze svých speciálních oblastí a pokusí se odházet dost zabraných stránek tak, aby se vytvořil spojitý buffer vhodné velikosti. Pokud jsou stránky v dané oblasti opravdu přesunutelné (skutečný svět někdy překáží), mělo by být možné dát ovladači buffer, který potřebuje. Když tento buffer není potřeba, paměť lze použít k jinému účelu.
Mohli bychom si položit otázku, proč je tento mechanismus vůbec zapotřebí, vzhledem k tomu, že shlukování paměti již teď umí vytvářet velké fyzicky spojité kusy pro transparentní velké stránky. Tento kód funguje, systém autora tohoto článku v době jeho psaní má cca 25 % paměti alokováno jako velké stránky. Odpověď je, že DMA buffery mají jiné požadavky než velké stránky. Mohou být například větší; transparentní velké stránky jsou na většině architektur 2 MB velké, zatímco DMA buffery mohou mít 10 MB nebo více. Také může být potřeba vložit DMA buffery do specifických rozsahů paměti, pokud je hardware dostatečně divný – a vývojář CMA Marek Szyprowski podle všeho opravdu podivný hardware má. A nakonec, velká stránka o velikosti 2 MB musí být také správně zarovnána, zatímco požadavky na zarovnání DMA bufferů obvykle bývají mnohem volnější. CMA alokátor může zabrat přesně požadovaný kus paměti (bez zaokrouhlování velikosti nahoru na další mocninu dvou, jako to dělá buddy alokátor), aniž by se zabýval příliš přísnými požadavky na zarovnání.
Sada patchů CMA poskytuje sadu funkcí pro nastavení oblastí paměti a vytváření „kontextů“ pro specifické rozsahy. Pak jsou zde jednoduché funkce cm_alloc() a cm_free(), které poskytují a uvolňují buffery. Očekává se nicméně, že ovladače zařízení nikdy nebudou volat CMA přímo; místo toho bude používání CMA zabudováno do podpůrných funkcí pro DMA. Když ovladač zavolá funkci jako dma_alloc_coherent(), automaticky se pro splnění požadavku použije CMA. Ve většině případů by to mělo „prostě fungovat“.
Jeden ze zbývajících problémů CMA je to, jak se speciální oblasti vytváří. Současné schéma očekává, že v souboru s definicí systémové desky bude speciální volání; je to velmi ARMistický přístup. Záměrem je těchto souborů se zbavit, takže bude potřeba přijít na něco jiného. Jak upozornil Arnd Bergmann, přesun této informace do stromu zařízení [device tree] není možný; je to rozhodnutí o politice. Arnd tlačí na vytvoření nějakého rozumného výchozího nastavení, které bude na většině systémů fungovat; obezličky pro systémy se speciálními problémy lze přidat později.
Konečným výsledkem je, že než se tato sada patchů dostane do hlavní řady, pravděpodobně se objeví přinejmenším ještě jedna její iterace. CMA nicméně řeší skutečný problém, na který se naráží, aniž by k tomu používal hacky různé nekvality, které lze najít mimo strom. Kód má potenciál zajistit, že alokace fyzicky spojitých bloků bude spolehlivější a dopad na zbytek systému přitom bude minimální. Vypadá to jako něco, co stojí za to mít.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.