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: >