OSDev.org

After looking through chapter 11 volume 3 of the intel manuals on caching, I have a couple questions about the use of MTRRs and PAT bits:

1. As far as memory types/caching modes, it seems that the MTRRs do pretty much the same thing as PAT bits in allowing you to select memory types. Other than giving you more control/granularity, is there any reason that an OS would want to use PAT bits in paging structure entries? I can see how it would also be useful for overriding MTRR settings on a per-page/per-process basis, but I'm not even sure what that would be needed for. The reason I'm asking is that I'm trying to decide if it's worth it to write a module in my kernel to allow configuration of memory types.

2. From what I've seen on the forums and wiki, it appears that BIOS sets up MTRRs based on the system memory map. If this is the case, would there be any reason at all for my kernel to want to change the MTRRs? I've seen a few posts about modifying an MTRR for the video buffer, but other than that there doesn't seem like any reason to change them. It seems like the BIOS would be much better at determining the system memory map and configuring MTRRs on a per-system basis than my kernel could be...

Thanks for your help

Hi,

thestew42 wrote:1. As far as memory types/caching modes, it seems that the MTRRs do pretty much the same thing as PAT bits in allowing you to select memory types. Other than giving you more control/granularity, is there any reason that an OS would want to use PAT bits in paging structure entries? I can see how it would also be useful for overriding MTRR settings on a per-page/per-process basis, but I'm not even sure what that would be needed for. The reason I'm asking is that I'm trying to decide if it's worth it to write a module in my kernel to allow configuration of memory types.

In general, MTRRs should be used for the actual underlying memory types, because a CPU can make assumptions about whether other CPUs cache things (and avoid unnecessary bus traffic, etc) based on the MTRRs, but can't make those assumptions for PAT (and can't avoid unnecessary bus traffic, etc). However, there's a limited number of "variable range" entries, so if/when you run out you end up using PAT to make up for it. On top of that, PAT may be useful for special situations (overriding MTRR settings on a per-page/per-process basis).

thestew42 wrote:2. From what I've seen on the forums and wiki, it appears that BIOS sets up MTRRs based on the system memory map. If this is the case, would there be any reason at all for my kernel to want to change the MTRRs? I've seen a few posts about modifying an MTRR for the video buffer, but other than that there doesn't seem like any reason to change them. It seems like the BIOS would be much better at determining the system memory map and configuring MTRRs on a per-system basis than my kernel could be...

The firmware sets up most of the MTRRs, but only for things like RAM and the legacy BIOS area below 0x00100000. For memory mapped devices it mostly does nothing (e.g. leaves the entire "PCI hole" as uncached), so the OS may want to setup MTRRs for specific PCI devices (e.g. make display memory for each video card "write-combining", etc). The firmware is meant to leave one or 2 "variable range" entries for the OS to use for this purpose.

Also, sometimes the firmware just doesn't do a good job; and you might be able to save a few "variable range" entries (so you've got more for left over for PCI devices to use) by doing it again yourself. However; this is only a nice extra (if you get it right) and not something that is important, or something that has to be done before "your OS version 1.0" is released.


Cheers,

Brendan