[OSy] fyzicka pamet
Martin Decky
decky at d3s.mff.cuni.cz
Mon Nov 28 12:51:26 CET 2011
Hezky den,
> Omlouvám se za špatně formulovaný dotaz, budu konkrétnější. Píši správu
> fyzické paměti v systému, přičemž nejpřímočařejší (ve smyslu nejméně
> komplikací a práce) metoda by byla vypnout TLB pomocí ELR = 1, namapovat
> 1:1 fyzické a virtuální adresy v rozsahu 0x00000000 až 0x80000000,
> osahat první 2GB a zjistit, kolik z té paměti tam skutečně je a tu potom
> spravovat.
Ten problem se zrejme rozpada na dva podproblemy:
1) Detekce platnych rozsahu fyzicke pameti.
2) Sprava rozsahu fyzicke pameti.
Specialne zduraznuji, ze zde hovorime o rozsazich, ne pouze o velikosti.
Nebyva totiz neobvykle, ze velikost fyzicke pameti je relativne mala (a
neni tudiz problem ji v MSIMu nakonfigurovat), ale bude v numericky
vzdalenych a vzajemne nesousedicich rozsazich.
Co se tyce podproblemu 1), u nej skutecne nevidim duvod
nenaimplementovat jednoduchy algoritmus, ktery bude postupne pomoci
docasneho TLB mapovani testovat jeden fyzicky ramec za druhym, zda do
nej lze zapsat. Takto muzete bez problemu zjistit, jake rozsahy fyzicke
pameti jsou platne, v celem intervalu 0 - 4 GB.
Na druhou stranu, je asi akceptovatelne, kdyz bude celkovy pocet
podporovanych rozsahu omezen nejakou rozumnou konstantnou (32). To z
toho duvodu, ze tu detekci fyzicke pameti provadite v okamziku, kdy si
musite vystacit se statickymi zaznamy.
Mimochodem, tomu Vasemu alternativnimu navrhu moc nerozumim. Nevim, o
jake hodnote ELR mluvite a jak presne chcete bez TLB vyrobit identicke
mapovani pro prvni 2 GB fyzicke pameti.
Co se tyce podproblemu 2), tak jen zopakuji, co jsem uz psal v
predchozim emailu. Dovedu si predstavit rozumne a prakticke duvody
proto, aby byla napriklad kernelova pamet omezena na prvnich 0.5 GB
fyzicke pameti, ktera je pristupna pres KSEG0. Ale bylo by fajn, kdyby
pamet uzivatelskych procesu, ktera je stejne mapovana pres TLB, takove
omezeni nemela.
> Při správě paměti bych pak nemusel řešit problémy s TLB. Je to
> korektní řešení?
Opet Vam trochu nerozumim. Jaktoze by se nemusel resit "problem" s TLB?
To chcete implementovat neco na zpusob single address space? Jakym
zpusobem budou adresove prostory jednotlivych procesu oddeleny? A jak se
chcete zcela vyhnout pouziti TLB (vyjma segmentu KSEG0 a KSEG1)?
> Důvod je zcela upřímně ten, že jsem už nějakou dobu seděl nad správou
> paměti a s použitím TLB jsem chtěl prozkoumat celé 4GB potenciální možné
> fyzické paměti, nicméně tam mám patrně nějaký bug, kterých byl ladil
> dalších X desítek hodin, přičemž mi to přijde jako naprosto zbytečná
> práce, když stejně nikdo nikdy více než 2GB paměti v tom MSIMu nepřidělí.
Jak uz jsem psal vyse, uvedomte si, ze v MSIMu nemusi uzivatel
nakonfigurovat 2 GB souvisle fyzicke pameti. Ale muze chtit treba
nakonfigurovat 16 MB fyzicke pameti od adresy 0 a 16 MB fyzicke pameti
od adresy 0xc0000000.
Zkuste zapojit zdravy rozum a uprimne si odpovedet na otazku: Je fakt,
ze nejaky algoritmus neni uplne trivialni a mam v nem chyby, ktere musim
odladit, skutecne korektni duvod rici, ze danou vlastnost muzu uplne
zahodit?
Nedovedu na tu otazku odpovedet za Vas -- nevim, jak vypada zbytek
Vaseho memory managementu a kernelu, jakou praci jste si s ostatnimi
vecmi dali, jak to mate navrzene a jaky je celkovy kontext veci.
M.D.
More information about the NSWI004
mailing list