OSDev.org

Hey,

Am I correct in assuming that the cache options (WC/WT etc) are ONLY available if you're running paging mode and have these flags configured in your page table / dir?
In which case you really should use paging EVEN if it were slightly slower to translate due to the massive gains you'd have come time to implement mem i/o and frame-buffers etc where you'd want uncached and write-combining?

John

Hi,

johnsa wrote:Am I correct in assuming that the cache options (WC/WT etc) are ONLY available if you're running paging mode and have these flags configured in your page table / dir?
In which case you really should use paging EVEN if it were slightly slower to translate due to the massive gains you'd have come time to implement mem i/o and frame-buffers etc where you'd want uncached and write-combining?

Without paging, cache controls consist of:

• The CD and NW flags in CR0 (which effect everything)
• The MTRRs (Pentium and newer CPUs?) which can be used to set the cache type for certain ranges (but there's normally only one or two variable ranges free for OS use)

With paging, cache controls consist of all the above plus:

• The PCD and PWT flags in CR3 (which effect everything in that address space)
• The PCD, PWT and PAT (if PAT is supported) flags in page table entries (and page directory entries for large pages)
• The PAT MSRs (if PAT is supported)

Even if PAT is supported by the CPU, it's still better to use MTRRs if they are available.

Given that write-combining (and potentially write-through) is only really used by video cards, for devices the only real advantage you get with paging for caching is better support for multiple video cards.

However, in some cases for normal RAM caching gets in the way. For example, if a piece of software reads a large array and pushes everything else out of the cache (but doesn't re-use anything it did cache) then it's better to disable caching for the large array to avoid the cache pollution. This is the main reason for the PCD and PWT flags in page table entries. Without paging you can disable all caching or mess with MTRRs during every task switch, but both of these ideas suck more than letting the cache get trashed.


Cheers,

Brendan

Ok thanks for the info!

In regards to PAE/PSE-36 which mechanism is best to use these days? PAE and ignore the PSE-36 stuff?

It depends...

PSE-36 has the advantage of being compatible with legacy paging, but it only works on a 4M basis, and if it's not supported you can't access the RAM above 4G while PAE can.
PAE has the advantage of having fine grained control over pages in higher memory, but isn't supported on older computers.

Combuster wrote: PAE... isn't supported on older computers.

actually, if PAE isnt supported then PSE-36 certainly wont be, since PSE-36 is newer than PAE


PAE first appeared in the original P6 (the PentiumPro)
PSE-36 first appeared in the PIII

(source: 3A:3.3)

given this fact, plus the fact that PAE can address the full physical address space (even in PMode), imho, PSE-36 should be generally ignored and just use PAE

AFAIK AMD introduced PAE in their Athlon series(correct me if I'm wrong) that means if you go for PAE-only then many AMD processors wont be supported, but this isn't a big issue if you dont care about the old stuff.

cyr1x wrote:AFAIK AMD introduced PAE in their Athlon series(correct me if I'm wrong) that means if you go for PAE-only then many AMD processors wont be supported, but this isn't a big issue if you dont care about the old stuff.

While you're right, PAE wasn't available on (m)any of the 586-class AMD processors.. but neither was PSE36.

Hi,

Don't forget that on newer 64-bit CPUs, PAE has been extended so that a 32-bit OS (that doesn't use long mode at all) can use larger physical addresses (whatever the CPU supports, up to 52-bit) and NX/XD. If you're only writing one 32-bit kernel, then this can make PAE an attractive option - you wouldn't be able to support older CPUs, but you would have reasonable support for newer computers.

If you want to support all computers well, the best method would be to have a "32-bit plain paging" kernel, a "32-bit PAE paging" kernel and a 64-bit kernel, where your boot code decides which kernel is the best kernel to use during boot. Note: If 32-bit physical addresses are enough to access everything and the CPUs don't support NX/XD, then there's no advantage in using PAE and it's better to use plain paging instead, because page tables, etc cost twice as much RAM for PAE.


Cheers,

Brendan

A good thing with PAE is you can statically allocate the kernel directory(s) once and you don't have to copy the pagetables everytime. This also makes synchronizing kernel page tables easier, which is essentially if you want to swap kernel pagetables. So the memory-usage-"impact" is a bit lower (you can even save some).