[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