[OSy] fyzicka pamet

..:: Urza ::.. urza at rdx2.cz
Mon Nov 28 16:38:15 CET 2011


Dobrý den.


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

Tohle mě skutečně překvapilo a netušil jsem, že toto musí náš systém umět. Předpokládal jsem (a nepovažoval jsem vůbec za nutné se na to ani ptát, protože mi to přišlo zcela samozřejmé), že fyzická paměť bude prostě v jednom souvislém bloku.
Když to teď říkáte, vlastně není žádný důvod, proč by to tak muselo být, jen jsem to pokládal za samozřejmé, protože mě vůbec nenapadlo, že by to mohlo být jinak, takže jsem detekci prováděl tím způsobem, že jsem skončil ve chvíli, kdy jsem objevil první adresu, na které není funkční paměť.

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

Dobrá, naimplementuji to tak.

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

Dočetl jsem se to v manuálu, mluvím o ERL flagu status registru v kernel mode, konkrétně o tomto:
When ERL = 1 in the Status register, the user address region becomes a
231-byte unmapped (that is, mapped directly to physical addresses)
uncached address space. See the Cache Error exception in Chapter 5 for
more information.
Pochopil jsem tak, že tím vytvořím identické mapování prvních 2GB paměti.

> 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.
> 
> 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)?

Nastavením ERL flagu status registru na 1, pokud jsem správně pochopil to, co jsem přečetl v tom manuálu.

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

Ne, to samo o sobě rozhodně ne, jen se mi nechce (resp. nechtělo, dokud jste mi nedal jiné důvody) ladit chyby v algoritmu, který je zbytečný, když to lze vyřešit jinak.
Respektive přesněji řečeno, dokud jste mi neřekl o nesouvislých blocích fyzické paměti na různých adresách, měl jsem pocit, že je to zbytečné, protože jsem chtěl prostě s fyzickou pamětí operovat pouze v rozsahu adres 0x00000000 až 0x80000000, což by stačilo pro mapování 2GB paměti za předpokladu, že bude celá v jednom bloku, což jsem prostě (patrně mylně) předpokládal.


Urza


PS: Stále mi opakujete (myslím, že už potřetí, počítám-li i můj dotaz z minula), abych používal zdravý/selský rozum. Věřte, že jej používám a sedím nad tím systémem mnoho hodin.... jen prostě nemám takový vhled do problematiky jako máte Vy, takže mě některé věci prostě nenapadnou (viz. mapovat fyzickou paměť ve více nesouvislých blocích), případně mi nejsou jasné věci, které Vy už dávno víte.... to ale neznamená, že jen tak spamuji mailing list otázkami, na které bych si mohl snadno odpovědět, kdybych pár minut přemýšlel.... než se na něco zeptám, skutečně to dlouze řeším, jen třeba ze špatného/omezeného úhlu pohledu.




More information about the NSWI004 mailing list