[OSy] Problem so zapisovanim do do virtualnej pamete

[Miroslav Cermak]

jj, tak ten podivny vypis bol sposobeny tym cim popisujes. Stale, ale mame
problem so zapisom do virtualnej pamate.

To co sa nam deje je detailne popisane tu ..

0.
TLB je prazdne

1.
Test si naalokuje pamat 0xc0000000 a zapise do nej;
<0,0> .. cycle 0 (actionno: 0) -- vma_alloc (size=0x1000) = EOK,
ptr=0xc0000000

TLB vyhlada mapovanie a zapise do tabulky zaznam;
[30] : Virtual Address=0xc0000000 ;Even=0x40a800 [D=1,V=1,G=0]; ODD=0x0
[D=1,V=0,G=0] ; ASID=1

(Uz v tomto momente pri vypise virtualnej pamate 0xc0000000 vypise 255, co
je obsah FYZICKEJ pamate aj na 0xc0000000
stranka 0x40a800 obsahuje same 00.)

2.
Test sa poskusi pristupit k naalokovanej pamati a nenajde tam ocakavanu
hodnotu;
<0,0> .. cycle 0 (actionno: 1) -- access (ptr=0xc0000492) = 255, expected 18

Ziadna tlb exception sa nevyhodi a v tabulke je stale ten jediny zaznam;
[30] : Virtual Address=0xc0000000 ;Even=0x40a800 [D=1,V=1,G=0]; ODD=0x0
[D=1,V=0,G=0] ; ASID=1

Mame pocit, ze bezime v nejakom divnom rezime. Ako keby pri nacitani pamate
pouzival virtualnou adresou namiesot namapovanej fyzickej,
pripadne sa dival niekam este uplne ako ma. Zapisuje tiez ktoviekam. Nemali
ste niekto z Vas podobny problem? Dakujem za odpoved.


On 12/5/07, Andrej Krutak <andree182 at gmail.com> wrote:
>
> Aha,
>
> teraz ma napadla este jedna vec - co sa stala aj mne pri testovani.. :-)
>
> Mozno mate "blbo" napisany ten testovaci kod - v tom zmysle, ze je
> prekladac
> hyperinteligentny a zoptimalizuje ten kod tak, ze ked si date vypisat
> obsah
> pamati, kam ste predtym zapisali, tak to vlastne vypise iba nieco, co si
> ten
> program "pamata" este v registroch (napr.), miesto toho aby sa naozaj
> pozrel
> cez TLB a do RAM.... (cache to urcite nebude, pretoze msim ziadnu
> nesimuluje,
> afaik :-D)
>
> Mohlo by pomoct nastavit ten pointer do pamati ako volatile, alebo medzi
> zapis
> a citanie pridat nejaku pointerovu aritmetiku (ptr+=1, -=1) - cim by sa
> mohla "vypnut" optimalizacia...
>
> (Ta optimalizacia ma prave take zaujimave efekty, ze aj ked zapises cislo
> na
> uplne nahodnu adresu (napr. neexistujucu pamat v KSEG0), tak ked precitas
> spat, tak tam ta hodnota bude - aj ked sa nikde do ram nezapisala...)
>
> Andrej
>
>
> On Wednesday 05 December 2007 01:40:08 Martin Choma wrote:
> > Caute,
> >
> > riesime jeden zahadny problem. Mame alokovany blok pamete vo virt.
> > priestore a k nemu alok. blok fyzickej.
> > Pri pokuse o zapis na virtualnu adresu sa nam vyhlada tlb zaznam so
> > spravnym mapovanim a zapiseme.
> > Este vypis premennej hned po tomto zapise vypise spravne priradenu
> > hodnotu (co moze byt sposobene cache).
> > Ale ak si vypiseme predchadzajucu premennu, do ktorej sme priradovali,
> > tak ta obsahuje hodnotu 255
> > (co je hodnota pri pohlade na fyz. adresu 0xCxxxxxxxx v memory dumpe
> > msimu). Ked sa pozrieme na danu
> > fyzicku pamat memory dumpom, tak je skutocne nevyplnena. Ako keby sa
> > to nezapisovalo alebo zapisovalo
> > niekam inam. Nenapada niekoho, cim by to mohlo byt? Diky.
> >
> > priznaky ksu exl a erl mame nastavene takto;
> > ksu = 0, exl=0, erl=0
> >
> > nase zaznamy v TLB vyzeraju asi takto:
> >
> > [0] : Virtual Address=0xc00ec000  ;Even=0x4fd800 [D=1,V=1,G=0];
> > ODD=0x4fe800 [D=1,V=1,G=0] ; ASID=1
> > [1] : Virtual Address=0xc00ee000  ;Even=0x4ff800 [D=1,V=1,G=0];
> > ODD=0x500800 [D=1,V=1,G=0] ; ASID=1
> > [2] : Virtual Address=0xc00d4000  ;Even=0x4e5800 [D=1,V=1,G=0];
> > ODD=0x4e6800 [D=1,V=1,G=0] ; ASID=1
> > [3] : Virtual Address=0xc00e4000  ;Even=0x4f5800 [D=1,V=1,G=0];
> > ODD=0x4f6800 [D=1,V=1,G=0] ; ASID=1
> > [4] : Virtual Address=0xc00ea000  ;Even=0x4fb800 [D=1,V=1,G=0];
> > ODD=0x4fc800 [D=1,V=1,G=0] ; ASID=1
> > .
> > .
> > .
> >
> > Martin Choma
> >
> > _______________________________________________
> > OSy mailing list
> > OSy at dsrg.mff.cuni.cz
> > https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>
>
>
> _______________________________________________
> OSy mailing list
> OSy at dsrg.mff.cuni.cz
> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20071205/32a78ce6/attachment.html>