[OSy] kernel heap limit

[Martin Decky]

Hezky den,

> Mám upřesňující otázku ke kernel heapu. V zadání (ohledně kernel
> heapu) stojí, že "soucasne s timto alokatorem bude stranky fyzicke
> pameti alokovat take volani frame_alloc()". Může se tedy stát, že
> naalokuji napřed kousek kernel heapu, potom někdo někde zavolá
> frame_alloc() a poté zas alokuje kernel heap.... kernel heap pak bude
> rozkouskovaný. Vzhledem k tomu, že kernel nepoužívá na svém heapu
> mapování (resp. pouze přímé přes KSEG0), bude ten heap rozkouskovaný
> jak ve fyzické, tak i ve virtuální paměti.... musí tedy malloc a free
> umět pracovat s rozkouskovaným heapem?

Ano, myslim si, ze by mel umet pracovat s rozkouskovanym heapem. Jina 
otazka je, jak to presne udelat -- to uz zadani nechava na Vas. Muzete 
implementovat podporu rozkouskovaneho heapu, podporu pro nekolik 
spojitych heapu, muzete zkusit svazat frame a heap alokator tak, ze pri 
oznaceni ramce jako pouzity se soucasne oznaci fiktivni cast heapu jako 
pouzita atd.

> Další možnost řešení by byla naalokovat heap předem na nějakou fixní
> velikost (tak to tam mám udělané teď), ale předpokládám, že to asi
> není z různých důvodů žádoucí (např. proto, že na kernel heapu
> ukládáme struktury vláken, jejichž počet má být podle prvního zadání
> omezen jen dostupnou pamětí

Vase analyza je presna, takove omezeni by asi nebylo vhodne.

> - což by tedy mohlo být problematické i
> vzhledem k tomu, že kernel heap má být jen v KSEG0, takže pokud
> předpokládáme, že vlákna ukládáme na kernel heap, je to omezeno
> dostupnou pamětí jen do jisté míry, konkrétně do míry 512MB).

Ano, ale to uz lze pro zmenu povazovat za relativne prirozene omezeni. 
Ne, ze by se nedalo obejit (nikdo Vam nezakazuje implementovat pro 
kernelovy heap moznost on-demand mapovani nad ramec vyuzivani KSEG0), 
ale da se pochopit, kdyz to neudelate.

> Každopádně z toho, co jsem se o heapu dozvěděl na přednášce (pokud
> jsem to dobře pochopil), předpokládají algoritmy pro správu heapu
> spojitý adresový prostor.

Rozhodne ne vsechny. Napriklad SLAB alokator zadny takovy predpoklad 
nema a i jine jednodussi algoritmy (z kategorie first fit) lze pro praci 
s nespojitym heapem pomerne snadno upravit.


M.D.