Jaderné noviny – 12. 1. 2017: Hromadná alokace paměti bez nového alokátoru

28. 1. 2017 | Redakce

Články - Jaderné noviny – 12. 1. 2017: Hromadná alokace paměti bez nového alokátoru  

Stav vydání jádra. Citáty týdne: Andy Lutomirski a George Spelvin. Hromadná alokace paměti bez nového alokátoru.

Stav vydání jádra

V době psaní článku byl nejnovější vývojový kernel 4.10-rc3 vydaný 8. ledna. Linus k tomu řekl: „Jeví se menší než jiné rc3, ale na první rc po začleňovacím okně (tzn. přirovnal bych ho k běžné rc2) je vlastně celkem normální.“

Stabilní aktualizace: 4.9.1, 4.8.16 a 4.4.40 byly vydány 6. ledna. 9. ledna následovala vydání 4.9.2, 4.8.17 a 4.4.41. Z toho 4.8.17 je poslední v řadě 4.8.x.

Velké aktualizace 4.9.3 a 4.4.42 pak vyšly 12. ledna.

Citáty týdne

Pokaždé, když KASLR způsobí, že něco funguje jinak, stane se z koťátka Schrödingerova kočka.

– Andy Lutomirski

Pro mě představuje mm/ prázdné místo na mapě, označené jako „Zde jsou lvi.“ I když je to lepší než „Zanechte naděje, kdo vstupujete,“ pořád je to děsivé.

– George Spelvin

Hromadná alokace paměti bez nového alokátoru

Jádro se potýká s celou řadou problémů se škálovatelností, což vyplývá z rostoucích přenosových rychlostí periferií jako úložiště a síťová rozhraní. Klíčem ke zlepšení propustnosti často bývá dělení práce do dávek. V mnoha případech není režie zpracování skupiny souvisejících operací o moc vyšší než při provádění jediné operace. Alokace paměti je právě případ, kdy dávkování nabízí potenciál pro výrazné zlepšení výkonu, zatím se však nepodařilo dojít ke shodě, jak by mělo probíhat. Nová sada patchů Mela Gormana by nám mohla ukázat, jak tento problém vyřešit.

Síťová rozhraní mají tendenci vyžadovat hodně paměti. Ostatně, všechny ty příchozí pakety je potřeba někde ukládat. Ovšem režie alokace této paměti je vysoká natolik, že může omezit maximální propustnost systému jako celku. Vývojáři ovladačů se proto uchylují k obezličkám jako alokace (a následné rozdělení) stránek vyššího řádu, což ale může zatěžovat systém jako celek a je to v rozporu s běžnou praxí při vývoji jádra. Bylo by dobré mít nějakou lepší alternativu.

Na loňském summitu věnovaném úložištím, souborovým systémům a správě paměti navrhl síťový vývojář Jesper Dangaard Brouer na zelené louce napsat nový alokátor paměti právě pro dávky operací. Ovladače by ho mohly používat k přidělení více stránek jediným voláním, čímž by se minimalizovala režie na stránku. Vývojáři správy paměti problém pochopili, ale nesouhlasili s vytvořením nového alokátoru. Podle nich by to totiž zhoršilo udržovatelnost subsystému správy paměti. Navíc by nový alokátor nejspíš opakoval chyby těch stávajících a jakmile by získal všechnu požadovanou funkcionalitu, už by nemusel být o nic rychlejší.

Z hlediska správy paměti je správným řešením modifikace již existujícího alokátoru stránek, snížení režie a zjednodušení vícestránkových alokací. Zatím k tomu nedošlo z jednoho prostého důvodu: většina uživatelů paměti okamžitě vynuluje každou stránku, která je jim přidělena, a to je operace mnohem nákladnější než samotná alokace. Nulování stránek, které budou přepsány příchozími pakety ze síťového rozhraní, není nutné, takže na výkon náročné síťové úlohy jsou výrazněji ovlivněny právě režií alokátoru. Odbourání režie v existujícím alokátoru stránek by problém napravilo pro síťový subsystém a zároveň by se šlo vyhnout vytváření nového alokátoru – navíc by se zlepšil výkon ve všech částech jádra.

Ten nápad dával smysl, ale měl jeden nedostatek: nikdo neudělal tu špinavou práci na vylepšení alokátoru. Situace se změnila až s představením Gormanovy sady patchů pro hromadnou alokaci stránek. Patche jsou poměrně malé, ale uváděné výsledky představují výrazné zlepšení výkonu alokace stránek.

Aby byly podporovány oba druhy alokace, je zapotřebí dvou zásadních změn, které se sobě podobají. První se týká funkce buffered_rmqueue(), která v rámci přípravy na vydání při požadavku o alokaci stránku odstraní ze seznamu volných stránek procesoru. Jelikož je seznam vyhrazený pro každý procesor, není potřeba před provedením změn nic zamykat, ale stále je nutné zakázat přerušení na příslušném procesoru, aby se zabránilo souběžnému přístupu obsluhy přerušení. Zakázání a opětovné povolení přerušení trvá nezanedbatelně dlouho a tento čas se nasčítá v případě, že je třeba tak učinit opakovaně pro každou alokovanou stránku.

Gormanova sada patchů tuto funkci rozděluje způsobem, který je při jaderném vývoji běžný. Nová funkce (__rmqueue_pcplist()) stránku odstraní ze seznamu, ale o vypnutí přerušení se nestará – očekává se, že se o to postará volající funkce. Volání rmqueue_pcplist() (bez úvodních podtržítek) zakáže přerušení a stránku alokuje běžným způsobem. Nově tedy jiný kód může jednou vypnout přerušení a poté zavolat funkci __rmqueue_pcplist() vícekrát, aby alokoval celou skupinu stránek.

Podobně volání __alloc_pages_nodemask() stráví značné množství času zjišťováním, která oblast paměti by měla být použita, aby byl splněn požadavek, a pak vrátí stránku. I v tomto případě je možné dílčí dvě operace rozdělit, aby se výpočet oblastí dal použít pro více alokací stránek – namísto opakování pro každou stránku.

Díky těmto dvěma změnám může Gormanova sada patchů přidat novou alokační funkci:

unsigned long alloc_pages_bulk(gfp_t gfp_mask, unsigned int order,
                               unsigned long nr_pages, struct list_head *list);

Tato funkce se pokusí efektivně alokovat nr_pages stránek, uloží je do daného seznamu list. Argument order naznačuje, že bude možné provádět hromadné alokace různých velikostí, leč v současné podobě patche dojde k chybě, je-li hodnota nenulová, tudíž zatím jsou podporovány jen samostatné stránky.

Gorman tvrdí, že výsledkem nasazení tohoto rozhraní je „zhruba 50-60% snížení ceny alokace stránek.“ To by mělo síťovým vývojářům pomoci ve snaze o zlepšení míry propustnosti paketů. Ale bude přitom zapotřebí trocha práce. Gorman předvedl možnost snížit režii alokace paměti, ale už se nedostal k vytvoření API se všemi funkcemi, které síťoví vývojáři potřebují. Jeho plán je sloučit přípravné patche bez API alloc_pages_bulk() s tím, že API pro hromadnou alokaci by měli navrhnout vývojáři, kteří ho potřebují. Takže jakmile se tyto změny dostanou do hlavního stromu, bude na týmu, který se sítěmi zabývá, aby s nimi udělal něco užitečného.

Diskuse k tomuto článku

[Michal2]

HP (hnidopišsķá poznámka):Hic sunt dracones = Zde jsou lvi? To jsou věci... Tady je překlad IMO kontraproduktivní; v originále je latina a měla by tam zůstat.

[Michal Kubeček]

Hic sunt dracones = Zde jsou lvi? To jsou věci... ;-)

V originále se někdy používají lvi, někdy draci, ale myslí se tím totéž. V češtině jsem variantu s draky asi ještě neslyšel, takže když už překládat, pak jsou lvi IMHO vhodnější.

Tady je překlad IMO kontraproduktivní; v originále je latina a měla by tam zůstat.

Naprosto souhlasím.

[Fluttershy, yay!]

Ona by tam pak asi měla zůstat i ta italština, u níž si nejsem jistý, s jakým pochopením by se setkala.

[Michal Kubeček]

IMHO by měla - přinejmenším mně se u toho původního citátu okamžitě vybaví, o co jde, zatímco u české verze mi to sice nakonec došlo taky, ale ne tak bezprostředně.

[Kvakor]

Lvi, tedy Hic sunt leones (resp. HIC SVNT LEONES) byly na starých středověkých mapách mnohem častější, draci byly jen na jedné nebo dvou, nicméně z nějakého důvodu jsou v anglosasské literatuře rozšířenější. Nicméně je zbytečné tam cpát originální latinu, to by se tam rovnou mohla dát i originální italšntina onoho citátu z Danteho Božské komedie

[Gilhad]

Tak me tak napadlo, jestli by bylo mozne, aby zlomyslny program (bez zvlastnich opravneni) opakovane naalokoval (ale nenuloval) spoustu stranek, procetl je a zase dealokoval v nadeji, ze z nejake vycte nejaka zajimava data (jak poznat, ze vubec zajimava jsou?) a ta pak zneuzije? (bezpecnostni programy byu mely nulovat veskerou pamet, nez ji dealokuji, ale je to zvykem i i "stredne bezpecnych"? Daji se takto treba ziskat POST hodnoty hesel k webu a podobne?)

[Michal]

Příloha:

• pamet.png (20098 bytů)

Na linuxu tohle je treba resit na aplikacni strane. Je zajimave, ze na vidows to je resene systemove. Ten vraci vzdycky vynulovanou pamet (ma kernelovy thread s nizkou prioritou, ktery stranky nuluje pokud neni vynulovana pamet k dispozici, tak to udela ad hoc) viz prilozeny obrazek- dva separatni seznamy stranek free (volne ale jeste nevynulovane) typicky jen par kB-MB, zeroed- vynulovane (v tomto pripade nejakych 171 GB).

[R]

Userspace proces nemoze dostat pamat, ktora by obsahovala nezmazane data z ineho procesu. To by bola diera ako hovado.

[Jindřich Makovička]

Za normálních podmínek to nejde, mmap() i sbrk() nově přidělenou paměť nulují. Vinou různých race conditions v mm se ale občas izolace procesů tak úplně nepovedla, takže rtorrent mi kdysi vesele sdílel kusy databáze z Chrome :)