Thema: 4Mb-Pages

[Scan]

Joa ich bin mal wieder dabei... hab wegen einer Lapalie irgendwie alles verloren, was ich mal vorgearbeitet habe.
Beim vorherigen Entwurf von Eyrin hat das Mirror-Mapping funktioniert, aber ich weiß nicht mehr wie. Ich wollte alles als eine liste von 4MB maps darstellen, damit ich 1024 page tables benutzen muss usw. sondern nur 2. Ich glaube, dazu sind die Dinger auch da.
Hab mir also das Intel Manual zu Herzen genommen und nachgesehen, und diesen Code gebaut:

Code: [Auswählen]

start:
mov eax, ebx
sub eax, (0xf0000000-0x00100000)
mov [multiboot], eax

push 2
popf

; First thing to do is setting up the memory to virtual memory

; At first: Mirror map all the memory from 0x00000000 to 0xf0000000

mov eax, 0x00301000
mov ebx, 0x00000083
mov ecx, 0xf00 / 4
.loop1:
mov [eax], ebx
add eax, 0x04
add ebx, 0x00400000
loop .loop1

or dword [0x00301000], 0x10 ; Disable cache for the first 4 MB in memory (too much movement)

; Second: map physical memory from kernel start to kernel end to 0xf0000000
extern __kernel_phys_end__

mov eax, 0x00302000
mov ebx, 0x00100103
mov ecx, 0x1000 / 0x04
.loop2:
mov [eax], ebx
add eax, 0x04
add ebx, 0x1000
loop .loop2

; Then set the directory up

mov dword [0x00300000], 0x00301103
mov dword [0x00300f00], 0x00302103

mov eax, 0x00300000
mov cr3, eax

; Set PSE flag
mov eax, cr4
or eax, 0x10
mov cr4, eax

; Set Paging
mov eax, cr0
or eax, 0x80000000
mov cr0, eax
Okay ich bin mit kommentaren sparsam, aber es sollte soweit ersichtlich sein. Der Kernel liegt physikalisch an 0x00100000 und virtuell bei 0xf0000000 und wird offensichtlich ordentlich gemappt. Aber mein Problem ist jetzt folgendes: Beim nächsten Schritt versucht der auf Speicher zuzugreifen, auf 0x00100090 oder so, dass allerdings aus irgendeinem Grund nach 0x40000000 gemappt worden ist. Und weiß nicht wieso, ich hab doch alles ordentlich gesetzt oder?

TFYA

[kevin]

Dir ist aber schon klar, was ein Page Directory macht und was die Page Tables machen?

Die Page Table Nummer n enthält das Mapping für den Speicherbereich von n*4 MB bis (n+1)*4 MB - 1 Byte. Was du hier also machst...

Code: [Auswählen]

mov dword [0x00300000], 0x00301103
mov dword [0x00300f00], 0x00302103...ist, daß du Page Tables für insgesamt 8 MB aufsetzt. Ups, das war nicht, was du wolltest?

Wenn du dein Zeug an 0x300100 als Page Directory nimmst (in dem werden nämlich 4 MB-Pages definiert), könnte noch ein Schuh draus werden. Dort mußt du halt an der entsprechenden Stelle im PD (die Ermittlung sei dem geneigten Leser zur Übung überlassen) noch die Page Table für den Kernel eintragen.

[Scan]

Achso die 4MB pages werden anstelle der Page tables in das Directory geschrieben! Wieder schlauer geworden... 
Jetzt funktioniert es, danke sehr 

[bitmaster]

4 MByte pages, soo grooooooooooß?? 

Davon würde ich abraten. Aber musst du natürlich selber wissen. Es lebe 4 KByte. ^^

bitmaster

[RedEagle]

Man muss ja nicht nur 4MB-Pages verwenden....
Ich habe 3 * 4MB - Pages für mein kernel reserviert. Alles andere wird mit 4KB-Pages gemacht...

[bitmaster]

Naja, die fürchterlichen 4 MByte pages gibt es im LongMode sowieso nicht mehr (da sind es dann höchstens 2 MByte ^^).

bitmaster

[kevin]

Und es wird von AMD dringend empfohlen, diese 2-MB-Pages auch zu benutzen. So ungeschickt ist diese Größe (und auch die 4 MB) für manche Zwecke auch gar nicht.

[bluecode]

Und es wird von AMD dringend empfohlen, diese 2-MB-Pages auch zu benutzen.

Interessant dazu ist auch Brendans Post aus dem osdev.org Forum: siehe hier (3ter Post von Brendan in dem Thread, Letzter Absatz).

[kevin]

Ich denke, so langsam kommen wir schon in Bereiche, wo man jedem Prozeß einfach mal auf Verdacht 2 MB geben kann. Dynamisches Aufsplitten und Zusammenfassen ist natürlich irgendwo theoretisch denkbar, dürfte praktisch gesehen aber nicht sinnvoll sein. Insofern stimme ich da schon zu.

Aber mal abgesehen davon kann man oft z.B. dem Kernel die großen Pages geben und dann davon profitieren, daß die Kernelpages so gut wie immer noch im TLB der großen Pages sind.

[bitmaster]

Ne ne, 4 KByte sonst nichts.

Mein ganzes OS (Kernel, Shell, Treiber etc.) verbrauchen zurzeit nicht mal 1,5 MByte.

bitmaster

[bluecode]

Ich bin hier mit bitmaster fast einer Meinung (kommt selten genug vor ). Ich möchte eigentlich nicht viel RAM sinnlos verschwenden und va. bei einem Microkernel lohnt sich die 4/2MB Page für den Kernel nicht und die 4/2MB Pages für die Treiber erst recht nicht. Ich nehme auch mal an, dass wenn man beides verwendet, dass man dann zuschauen kann wie schnell die 2/4MB Pages bei Auslastung total zerstückelt werden und die Wahrscheinlichkeit die wieder zusammenzufrickeln ist relativ gering würde ich mal vermuten und der Aufwand das zu managen ist wahrscheinlich auch um einiges größer.
Ich seh noch nicht so ganz, dass man für (Micro-)Kernel/Treiber/Apps 4/2MB Pages braucht.

[kevin]

Mein ganzes OS (Kernel, Shell, Treiber etc.) verbrauchen zurzeit nicht mal 1,5 MByte.

Und meine ganzen anderen schönen Megabytes bleiben ungenutzt, obwohl sich damit die Geschwindigkeit verbessern ließe? Es hat immer alles zwei Seiten.

[Scan]

Ich brauche die 4MB-pages nur an einer einzigen Stelle, nämlich für das mirror-mapping im Kernel. Sonst müsste ich, nur damit ich global auf den Speicher zugreifen kann, 1024 page tables bauen, jede mit 4 KB Speicherverbrauch, also schon alleine 4 MB nur für die mirror map verschwendet. So brauche ich nur 8 KB.

[bitmaster]

@bluecode : Geht es dir nicht gut? Wie kannst du nur mit mir einer Meinung sein?     

@taljeth: Na ja, also die 1,5 MByte sind so schnell geladen, das glaubst du gar nicht. Da würde kein Unterschied zu merken sein, was die Schnelligkeit betrifft. Was den RAM-Verbrauch betrifft schon.

bitmaster

[kevin]

@taljeth: Na ja, also die 1,5 MByte sind so schnell geladen, das glaubst du gar nicht. Da würde kein Unterschied zu merken sein, was die Schnelligkeit betrifft. Was den RAM-Verbrauch betrifft schon.

Ich rede ja auch nicht vom Laden, da ist es die Platte die bremst, nicht die CPU... Ich rede von der Ausführungsgeschwindigkeit der Programme, wenn sie mal geladen sind.

[bluecode]

Und meine ganzen anderen schönen Megabytes bleiben ungenutzt, obwohl sich damit die Geschwindigkeit verbessern ließe? Es hat immer alles zwei Seiten.

Das ist (zumindest) mir klar. Ich hab ja schon oben beschrieben, warum ich denke, dass sich der Aufwand für Kernel/Treiber/Apps nicht lohnt (va. im Microkernel).
btw. irgendwie erinnert mich das an Vista, das nach dem Start mal gleich einiges an Speicher für sich veranschlagt... 900MB wenn ich mich recht erinnere, aber um das zu verifizieren müsste ich es ja starten...

[bitmaster]

Na ja, vielleicht will taljeth ja ein ähnliches Vista bauen, welches Unmengen an Ressourcen verbraucht. *duck*

bitmaster

[bluecode]

Na ja, vielleicht will taljeth ja ein ähnliches Vista bauen, welches Unmengen an Ressourcen verbraucht. *duck*

Vorsicht! Er versteht heute keinen Spaß  

[kevin]

Vielleicht labere ich auch einfach nicht so viel Müll wie du?

Pages, die beispielsweise der Kernel als 2/4-MB-Pages gemappt hat, können für den Prozeß immer noch als 4k-Pages zur Verfügung gestellt werden. Und wenn wir uns mal erinnern, worum es in diesem Thread geht (ich weiß, interessiert dich nicht, bitmaster), dann geht es um Identity Mapping im Kernel. Wo wird denn da Speicher verbraten? Dort wird mit den großen Pages Speicher gespart, weil man keine Page Tables braucht.

[bitmaster]

@bluecode: Oo, wenn ich das gewusst hätte.

@taljeth:

Vielleicht labere ich auch einfach nicht so viel Müll wie du?

Na ja, aber dafür tut es dein LOST. ^^ hahaha 

Und wenn wir uns mal erinnern, worum es in diesem Thread geht (ich weiß, interessiert dich nicht, bitmaster)[...]

Das ist eine Frechheit so etwas zu behaubten.

bitmaster