MTRR

A little about how it works
MTRR stands for Memory Type range registers which is a new way of partitioning and managing memory resources in your system. This feature had been placed in processors due to memory sizes becoming bigger and bigger. There had to be a way that the memory could be allocated addressed and used more effectively.

A main feature of the MTRR is to map locations of PCI or AGP components in your system so that software, drivers could access them quickly and efficiently.

To check if your processor(s) have this feature you can type:

cat /proc/cpuinfo

For memory Information

cat /proc/meminfo

And for MTRR information

cat /proc/mtrr

When looking at your Processors(CPU) info you will see if your CPU supports MTRR, this will be said in the flags line displayed. You will also be able to see if your CPU has PAT support.

PAT Support Is a new type of memory type register which works with MTRR it works NOT as a MTRR but instead allows faster more flexible way in partitioning memory resources. Note PAT does not allocate the memory resources like MTRR does but takes control of the memory inside of what the MTRR has allocated. A fair statement would be to say for a system supporting MTRR and PAT would be: MTRR creates the memory mapping and PAT manages the tables inside of them.

The Kernel
Enabling MTRR and PAT

I will assume at this point you know how to setup and compile a kernel but for a completeness i shall include this.

cd /usr/src/linux

If the location does not exist, or the directory is empty, you do not have the symbolic links setup for your running kernel. If you have this setup correctly then jump to 'Set and make the kernel' missing this next section of code.

emerge the source code if you have not got them already emerge -av gentoo-sources Check your symbolic link: ls -l /usr/src/linux This should report that /usr/src/linux > /usr/src/Linux-2.6xx-gentoo-xx (x being the version of your kernel) if not then: ln -s /usr/src/linux /usr/src/linux-2.6.xx-gentoo-xx replace xx with the actual version that was emerged.

To set and make the kernel

Let's start the base kernel configuration menu with

make menuconfig

Once loaded navigate to here:

Processor type and features ---> [*] MTRR (Memory Type Range Register) support [*]  MTRR cleanup support (1)    MTRR cleanup enable value (0-1) (1)    MTRR cleanup spare reg num (0-7) [*]  x86 PAT support

If x86 PAT support doesn't show up as an option, then it is probably enabled by default. The following command will verify this.

grep CONFIG_X86_PAT /usr/src/linux/.config CONFIG_X86_PAT=y

An explanation is needed here, as there is very little information on the net not to mention the amount of times i am asked about this MTRR clean up support: This feature is a must if you wish to use X and/or Frame-buffer devices for your console. (1)    MTRR cleanup enable value (0-1) (1)    MTRR cleanup spare reg num (0-7) To choose correctly in setting these, you must understand what they are. (1)    MTRR cleanup enable value (0-1) This option is to actually enable the cleanup support and nothing more. If this is set to 0 then the kernel will not have cleanup enabled at boot time, you will have to enable this at the boot command line setting the value to 1. Setting it here specifies the default on condition so change it from 0 to 1

(1)    MTRR cleanup spare reg num (0-7) This option confuses most so to explain: This option tells the kernel and or drivers which reg number can be cleaned up or changed, for most systems it is the default number 1. This means that reg1 in your /proc/mtrr will be the line to remap. Here is a view of my /proc/mtrr when X windows is loaded with fglrx driver. cat /proc/mtrr reg00: base=0x000000000 (   0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back Note that the reg01 is actually a normal memory layout due to 3G/1G memory split option i have set my kernel up as, There is not section at point reg01 for my write-combined graphics card in fact that is missing all together. This is because the ATI fglrx driver has claimed it. If you use Frame-buffer either kernel or X.org then the setting will appear as reg03,4,5 etc and will be moved(remapped) from the reg01 slot IO hope that clears up the reason and how this setting in the kernel works. If when MTRR_cleanup is disabled you notice the base address of your graphics card is at a different regXX number then change the spare reg number to this accordingly so you can allow for the write-combined or as in my case proprietary driver to take control of it.

Let's build it once they're all set let's do it

make && make modules_install

Once compiled then: mount /dev/xxx /boot

replace xxx with your boot drive partition.

cp arch/i386/boot/bzImage /boot/kernel-2.6.xx-xx

That's it, you're done. Reboot and your MTRR is ready to be used properly.

The memory remapping feature in the bios
Clearing the myth of 32bit 4 GB memory remap and lost memory

This section is very related to MTRR as you will see shortly so read on if you want to know how to set this.

As mentioned above MTRR is a memory management protocol built into many new processors to managed fast writes and so on. In most motherboards there is a feature to set memory remapping, most people confuse this to 64bit systems and is not a feature intended for 32bit. Neither of these are true. Memory remapping simply means that it will remap devices overlapped by memory above 4 GB and for a 32bit system running unbuffered(NON Registered Dimms) memory 4 GB is the limit. The bios will still need to map resources such as graphics card aperture pci addressing etc so that they can be accessible to the Operating System. When 4 GB is installed in a 32bit it has no more space as 32bit can only deal with 4096 MB memory addressing so PCI and AGP cards need to share the address space hence it uses up memory that wont be able to be used.

Memory remapping will push all that addressing above 4 GB, by making the system see the full 4 GB memory and share address pointers redirecting addresses that were previously overlapped. This does happen at a performance cost as well. On 64bit systems the same is apparent but of course with much more memory (about 8 Peta Bytes).

MTRR can manage this well and there is nothing from the how-to above extra you need do. One thing to point out is that some proprietary drivers such as ATI fglrx drivers do not always work with this feature. I have had them working before but at reduced performance because of the remapping feature, other versions just fail to find the graphics memory address so if your having X driver problems Blank screen, Lockouts, hard lock crashes etc then Disable the remapping in the bios.

MTRR