Jaderné noviny – 10. 8. 2017: Jaderný subsystém genpool

24. 9. 2017 | Redakce | Jaderné noviny | 2890×

Stav vydání jádra. Vetter: Proč nemůže jaderná komunita sídlit na Githubu. Citát týdne: Neil Brown. Jaderný subsystém genpool.

Stav vývoje jádra

Současné vývojové jádro bylo 4.12-rc4 vydané 6. srpna. Linus řekl: „Každopádně nic nijak zvlášť nevybočuje a zatímco doufám, že se situace bude dále uklidňovat, vše vypadá vypadá, že jede v zajetých kolejích. Takže testujte, teď už by to mělo být docela bezpečné.“

Seznam regresí pro jádro 4.13 ze 6. srpna ukazuje 10 známých problémů.

Stabilní aktualizace: 4.12.5, 4.9.41 a 4.4.80 byly vydány 6. srpna.

Verze 4.12.6, 4.9.42, 4.4.81 a 3.18.64 byly v době psaní tohoto článku v procesu revidování, vyšly 11. srpna.

Vetter: Proč nemůže jaderná komunita sídlit na Githubu

Daniel Vetter píše o škálování komunity kolem vývoje jádra a o tom, proč si myslí, že model Githubu u největších projektů nefunguje. „GitHub bohužel nepodporuje tenhle způsob práce, přinejmenším ne nativně ve svém uživatelském rozhraní. Dá se toho samozřejmě dosáhnout pomocí obyčejných nástrojů gitu, ale znamená to návrat k patchům v e-mailové konferenci, žádostem o začlenění přes e-mail a jejich ruční aplikaci. Tohle je dle mého názoru jediný důvod, proč nemůže komunita z přechodu na github těžit. Pak je tady drobný problém, že několik hlavních správců je velmi hlasitě proti githubu obecně, ale to ve skutečnosti není technický problém. A nejde jen o jádro Linuxu, jde o všechny velké projekty na githubu, které mají problém se škálováním, protože jim github neposkytuje možnost škálovat do více repozitářů a zároveň udržovat jeden hlavní strom.“

Citát týdne

Můj strašák je navrhnout, abychom to uvolnili. Změníme slib z „pokud to funguje na vydaném jádře, bude to fungovat na všech jádrech vydaných v budoucnu“ na „pokud to funguje na N po sobě jdoucích jádrech, bude to fungovat na všech v budoucnu vydaných jádrech,“ potom se povedeme nekonečné diskuze o hodnotě N, ale pravděpodobně se shodneme na N=2. To by mělo poskytnout výraznou svobodu jaderným vývojářům a uvalit (doufejme) malé břímě na vývojáře aplikací. I tak by měli testovat svůj kód (všichni bychom měli), tak ho musí testovat dvakrát.

—Neil Brown

Jaderný subsystém genpool

The kernel's genpool subsystem. Jonathan Corbet. 3. srpna 2017

Jádro je obrovský program. To znamená, mimo jiné, že mnoho problémů, s nimiž se setká některý jaderný vývojář, již vyřešil někdo jiný jinde ve stromu. Problém je, že tato řešení nejsou vždy dobře známá nebo zdokumentovaná. Nedávno se zkušený vývojář přiznal, že se nikdy nesetkal s alokátorem paměti „genpool“. Tento malý subsystém se neobjevuje v jaderné dokumentaci a pravděpodobně nebude znám ani ostatním. Za účelem řešení obou těchto problémů následuje přehled o genpoolu (nebo „genalloc“) a o tom, co dělá.

V jádře existuje celá řada mechanismů pro alokaci paměti, každý zaměřený na uspokojení specifických nároků. Někdy však jaderný vývojář musí implementovat nový alokátor pro konkrétní rozsah paměti určené pro zvláštní účely, přičemž tato paměť často bývá uložená někde na zařízení. Autor ovladače tohoto zařízení jistě může pro tuto činnost napsat malý alokátor, ale tak by se jádro zaplnilo desítkami špatně otestovaných alokátorů. V roce 2005 vzal Jes Sorensen jeden z těchto alokátorů z ovladače sym53c8xx_2 a zveřejnil jej jako generický modul pro vytváření ad–hoc alokátorů paměti. Kód byl začleněn do vydání 2.6.13 a od té doby se značně změnil.

Akce začíná vytvořením fondu (pool) použitím jedné z následujících funkcí:

#include <linux/genalloc.h>

struct gen_pool *gen_pool_create(int min_alloc_order, int nid);
struct gen_pool *devm_gen_pool_create(struct device *dev, int min_alloc_order,
                                      int nid, const char *name);

Volání gen_pool_create() vytvoří fond. Granularita alokací je nastavena pomocí min_alloc_order, jedná se o číslo zlogaritmované se základem 2 – podobně jako u alokátoru stránek, ale odkazuje na bajty namísto stránek. Takže pokud je v min_alloc_order předáno číslo 3, pak budou všechny alokace násobkem osmi bajtů. Zvýšení min_alloc_order zmenšuje paměť potřebnou ke sledování paměti ve fondu. Parametr nid specifikuje, který uzel NUMA má být použit k alokaci pomocných struktur – může to být také -1, pokud na tom volající funkci nezáleží.

„Spravované“ rozhraní devm_gen_pool_create() sváže fond s konkrétním zařízením. Kromě jiného automaticky fond vyčistí v okamžiku, kdy dojde k zničení daného zařízení.

Fond je zrušen pomocí:

void gen_pool_destroy(struct gen_pool *pool);

Stojí za zmínku, že pokud jsou v daném fondu pool stále vyčleněné alokace, zvolí tato funkce poměrně extrémní krok a vyvolá BUG(), což shodí celý systém. Byli jste varováni.

Čerstvě vytvořený fond nemá žádnou paměť k alokaci. V takovém stavu je celkem k ničemu, takže jedna z prvních věcí, co je potřeba udělat, je obvykle přidání paměti do fondu. To se dá udělat dvěma způsoby:

int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size, int nid);
int gen_pool_add_virt(struct gen_pool *pool, unsigned long virt, phys_addr_t phys,
                      size_t size, int nid);

Volání gen_pool_add() umístí size bajtů paměti od začátku addr (ve virtuálním adresním prostoru jádra) do daného fondu pool, přičemž nid je opět ID uzlu pro pomocné alokace paměti. Varianta gen_pool_add_virt() paměti přiřadí explicitní fyzickou adresu, což je nutné pouze v případě, kdy se fond bude používat k alokacím DMA.

Funkce pro alokaci paměti z fondu (a její vracení) jsou:

unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size);
void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size, dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size);

Jak by se dalo čekat, gen_pool_alloc() alokuje size bajtů z daného fondu. Varianta gen_pool_dma_alloc() alokuje paměť k užití s operacemi DMA, vrací přidruženou fyzickou adresu v prostoru, na který ukazuje dma. To bude fungovat pouze v případě, že byla paměť přidána pomocí gen_pool_add_virt(). Všimněte si, že se tato funkce odchyluje od vzoru typického pro „genpool“, a sice místo obvyklého použití unsigned long pro adresy jádra vrací void *.

To vše se jeví poměrně přímočaré, některým vývojářům se to opravdu zdá přímočaré až příliš. Koneckonců výše uvedené rozhraní neposkytuje žádnou kontrolu nad tím, jakým způsobem alokační funkce vybírají, který konkrétní kus paměti vrátí. Pokud je to zapotřebí, budou se hodit následující funkce:

unsigned long gen_pool_alloc_algo(struct gen_pool *pool, size_t size,
                                  genpool_algo_t algo, void *data);
extern void gen_pool_set_algo(struct gen_pool *pool, genpool_algo_t algo,
                              void *data);

Alokace pomocí gen_pool_alloc_algo() určují algoritmus, pomocí kterého se vybere paměť k alokaci, výchozí algoritmus se dá nastavit pomocí gen_pool_set_algo(). Hodnota data je předána algoritmu – většina z nich ji ignoruje, ale někdy je zapotřebí. Samozřejmě je možné napsat algoritmus pro konkrétní případ užití, ale již je k dispozici docela solidní výběr:

• gen_pool_first_fit je jednoduchý alokátor typu first-fit. Jedná se o výchozí algoritmus, pokud není zvolen jiný.
• gen_pool_first_fit_align vynutí určité zarovnání alokace (předává se pomocí položky data ve struktuře genpool_data_align).
• gen_pool_first_fit_order_align provede zarovnání alokace podle řádu velikosti, takže např. 60bajtová alokace bude zarovnána na 64 bajtů.
• gen_pool_best_fit, jak by se dalo očekávat, prostě vybere nejlepší možnou alokaci.
• gen_pool_fixed_alloc provádí alokaci s daným offsetem (předává se pomocí položky data ve struktuře genpool_data_fixed) v rámci fondu. Pokud není požadovaná paměť dostupná, pak alokace selže.

Existuje několik dalších funkcí, většinou pro účely jako dotazování se na dostupné místo ve fondu nebo iterace přes kusy paměti. Většina uživatelů by však neměla potřebovat víc než to, co bylo popsáno výše. Snad větší povědomí o tomto modulu zabrání psaní nových jednoúčelových alokátorů paměti v budoucnu.

       

Komentáře