[osy] Re: frame_alloc

  • From: "Jaroslav Keznikl" <jaroslav.keznikl@xxxxxxxxx>
  • To: osy@xxxxxxxxxxxxx
  • Date: Mon, 17 Nov 2008 21:40:33 +0100

Lukas Jezek napsal(a):
>> myslim, nemuzeme si zadne znacky delat, to si muze delat sprava virtualni 
>> pameti, ale ne sprava fyzicke
> Znacky si delat muzeme, jen ne do tech bloku, ktere alokujeme - musime
> mit nejake struktury v pameti, ve kterych si budeme vsechno
> implementovat. Mit celou bitmapu volnych bloku v pameti podle mne neni
> vubec chytre - pametove zbytecne narocne - skoro nikdy nepotrebujes
> resit granularitu na uroven jednodlivych ramcu. Kdyz uz bych to
> implementoval, tak rovnou aspon kazdy bit 1 ramec - misto hranatych
> zavorek budes pouzivat funkci, ktera to bude prepocitavat - pouziva se
> to uplne stejne.
samozrejme reseni s mapou pameti je docasny, bude to chtit alespon
nejakej setridenej seznam nebo nejlip strom (a asi ne staticky
alokovanej, ale to bude malinko slozitejsi).
jinak co se tyce znacek v pameti, tak jsem myslel znacky toho typu co se
tam delali v alokatoru kalista (a Jirka asi taky), je jasny ze nekam si
udaje ukladat musime :D
>
> Virtualni pamet si muze delat tak akorat uplne stejny znacky do pameti
> jako fyzicka - proste si je dela do svych internich struktur.
>
> , ta toho mimochodem nema umet
>> vic nez jsou ty 2 fce, vsechno ostatni je zalezitost virtualni pameti nebo 
>> veci nad tim
>>
>> protoze sprava fyzicke pameti umi alokovat jenom cele ramce, takze ani neni 
>> spravne neco do pameti psat.
> Samozrejme, ze je - musis si nekde v pameti poznamenat, ze je ten
> ramec plny. Preusporadat si datove struktury nad tim atd...
>
to same jako nahore, myslel jsem spat si zacatky a konce bloku primo k
tem blokum, to da rozum ze je potreba si to ulozit nekam jinam, ale ne
tak jak to je ted v alokatoru kalista...

>  Myslim ze budeme muset dat schuzku a
>> jeste jednou si to projasnit, ale ja jsem si celkem jistej, ze vim co a 
>> jak...ridim se tim API co ma ktera cast delat...
>> J.
>>
>> Jiri Horky napsal(a):
>>> Jasne, ono si hlavne myslim ,ze casem prejdem na ty znacky primo v pameti, 
>>> nez na vyhrazene misto nazacatku, ne?
>
> 4GB pameti = 32 bitu adresace, 12 bitu = offset => 20 bitu je urceni
> ramce => 220 ramcu, ke kterym si musis pamatovat volno/plno = 217 bytu
> = moc zbytecne vyplytvanych ramcu volny pameti, ne (pocitam-li dobre,
> tak 32).
>
mapa je POUZE docasne reseni...
> Stejne budes muset postupne resit problemy typu dej mi souvisle 100
> ramcu -> musis si postavit nejakou strukturu nad timhle a ta asi tezko
> bude staticky alokovana -> i pro ni musis resit problem, jak zabrat
> ramec pro nove interni struktury a poznacit to do stavajicich
> struktur.
>
> Rek bych, ze spravny postup je:
> - zabrat si na zacatku frame, struktury si ukladat do nej, v pripade,
> ze dalsi struktura se do nej uz nevejde, tak:
>  - zabrat si dalsi volny frame a ten pouzivat na dalsi alokace.
>
tady bude akorat velky problem s uvolnovanim takhle zabranych ramcu, ale
asi je to ten spravny postup
> Otazka je, jestli se na tyhle interni struktury ma pouzivat malloc
> nebo ten ma stat nad tim (to si zatim s Jarou myslime)...
podle mne si to rozhodne  ma delat frame_alloc sam, protoze malloc
neboco je uz pomerne highlevel zalezitost (ktera pracuje s
>
> Malloc totiz rozhodne nema fungovat tak, ze by kazdy pozadavek na
> alokaci zarovnal na 4kB stranku a tu sebral a vratil do ni odkaz na
> zacatek. Spis ma mit naky ukradeny stranky, v pripade nutnosti si vzit
> dalsi a uvnitr nich provadet to, co provadi primo ve fyzicky pameti
> doted...
jo, otazka je kam nacpat ty alokacni strategie
>
>
> To jsou me poznatky, mozna spatne...
>
> L.
>
>
> P.S. Nejde mi to poslat z me IP - nejak mne odmita Mail:
>

Other related posts: