[SOLVED] What is "MTRR Cleanup spare reg num" About?
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So, here I am building a custom kernel but I came across this option "MTRR Cleanup spare reg num" and I can't "decode" what it's about. After a heavy but worthless google search, all I could came with is here: http://en.gentoo-wiki.com/wiki/MTRR - but, I can't understand it quite well.
mtrr are registers inside a brainy type of cpu. I'm in electronics, but at a certain point it became impossible to distinguish electronic specifications from marketing hype and I just glazed over. repeat your searches with the site:kernel.org and you'll get gigabytes on it from the guys who wrote this
MTRR cleanup is a form of garbage disposal, and as such is a good thing. I just picked cleanup values out of the air and the sky didn't fall in here.
I've read about MTRR Cleanup, and this part of the story is kind of clear to me. I mean, I was able to understand the concept about MTRR cleanup and it's actions, but my main question is about the value for "MTRR cleanup spare reg num", the one I couldn't figure out how does it work and what is the expected action in changing this value.
After some research, try-and-fail, the issue is solved. For anyone interested, here's what I've come to:
On the beginning of the kernel init, I have the fallowing output:
Code:
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000 mask F80000000 write-back
[ 0.000000] 1 base 07F800000 mask FFF800000 uncachable
[ 0.000000] 2 base 07F700000 mask FFFF00000 uncachable
[ 0.000000] 3 disabled
[ 0.000000] 4 disabled
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] original variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 2GB, type WB
[ 0.000000] reg 1, base: 2040MB, range: 8MB, type UC
[ 0.000000] reg 2, base: 2039MB, range: 1MB, type UC
[ 0.000000] total RAM covered: 2039M
[ 0.000000] Found optimal setting for mtrr clean up
[ 0.000000] gran_size: 64K chunk_size: 16M num_reg: 3 lose cover RAM: 0G
[ 0.000000] New variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 2GB, type WB
[ 0.000000] reg 1, base: 2039MB, range: 1MB, type UC
[ 0.000000] reg 2, base: 2040MB, range: 8MB, type UC
showing how the MTRR memory is configured. You can see that from the 8 registers, 3 are taken and 5 are free. The "mtrr_spare_reg_num" is about those 5 free registers, where MTRR cleanup can make use of. My graphics card (GMA965) has 8MB of dedicated memory and 256MB of shared memory. So, MTRR cleanup will take use of one of those registers using it as a write-combining.
My kernel command-line is configured as "mtrr_spare_reg_num=5", saying that 5 of the 8 registers are free for MTRR cleanup to use. When set to a value > 5, MTRR complains about cannot find a optimal setting, leading to a bunch of errors - of course, since it's saying that > 5 registers are free, when actually they are taken.
The MTRR cleanup, in my case, only use one register (reg 3) for the MTRR cleanup, keeping the other 4 registers free, and thus giving the /proc/mtrr output showed on the first post.
So, this is it. Thank you, business_kid, for helping me out.
Thanks for the info, I've always wondered what these mean, I think you are right, it means the number of spare (disabled) registers that it can use if it needs to ... I don't see why this cannot be auto-detected.
@rfernandez: Thank you very much for that. I suppose the kernel guys are not auto declaring it because it is a decision about how you configure your cpu. You/they may want to have other things use there registers, theoretically.
Does that boot parameter mtrr_reg_cleanup=5 apply on 32 & 64 bit boxes?
I'm glad that the information was useful; took me a while to understand the internet references and debugging my own kernel.
As H_TeXMeX_H said, this options refers to my own box, bussiness_kid, you'll have to check yours to see how many of those registers are free (if any). If i had, for example, registers 2, 3, 4, 5, 6 and 7, free, I could just use mtrr_spare_reg_num=6. I can, nonetheless, say to MTRR that I've only got one spare registers by just saying mtrr_spare_reg_num=1 to it, and it'll try to the the job with that one. You could do this if you'd like one register to be managed by MTRR automatically while you manage the others. The instructions on "how to mange mtrr registers" are under the ./Documentation/x86/mtrr.txt on the linux-kernel source code.
The x86 PAT is an enhancement for MTRR, from the ./Documentation/x86/pat.txt
Quote:
PAT (Page Attribute Table)
x86 Page Attribute Table (PAT) allows for setting the memory attribute at the
page level granularity. PAT is complementary to the MTRR settings which allows
for setting of memory types over physical address ranges. However, PAT is
more flexible than MTRR due to its capability to set attributes at page level
and also due to the fact that there are no hardware limitations on number of
such attribute settings allowed. Added flexibility comes with guidelines for
not having memory type aliasing for the same physical memory with multiple
virtual addresses.
PAT allows for different types of memory attributes. The most commonly used
ones that will be supported at this time are Write-back, Uncached,
Write-combined and Uncached Minus.
So it's always a good to choice to, if you enable MTRR, also enable x86 PAT.
I found this thread very interesting because I am trying to understand what is the right value to set for the "MTRR cleanup spare reg num (0-7)" in my kernel configuration.
I'm a gentoo user, so the first thing I've done is to read this wiki, where the value 1 is suggested. While reading this thread, I could understand that the value 1 is not correct, since it would be equal to the number of free registers.
I noticed many things here that are not reported by my system. For instance my /var/log/message doesn't contain any line like these:
There is something strange with my two PCs.
As regard the mtrr/pat kernel configuration, it is the same but my desktop PC shows the following messages at boot:
Code:
io scheduler deadline registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
lp: driver loaded but no devices found
Real Time Clock Driver v1.12b
Linux agpgart interface v0.103
uvesafb: NVIDIA Corporation, BIOS-P/N@N4273:0, Chip Rev , OEM: NVIDIA, VBE v3.0
uvesafb: VBIOS/hardware doesn't support DDC transfers
uvesafb: no monitor limits have been set, default refresh rate will be used
The strange behaviour is that these lines appear "tabbed" to the right of the screen, with respect to the other messages. Furthermore, these messages don't appear (or at least they don't appear as "tabbed" on the other PC which has a nVidia card as well and it uses mtrr/PAT.
I don't know if this has something to do with mtrr, but I had this problem in the past:
Code:
mtrr: type mismatch for fb000000,800000 old: write-back new: write-combining
mtrr: type mismatch for fb000000,400000 old: write-back new: write-combining
mtrr: type mismatch for fb000000,200000 old: write-back new: write-combining
mtrr: type mismatch for fb000000,100000 old: write-back new: write-combining
This has been solved "fully" enabling the MTRR support in the kernel. Now in place of the messages above I see the messages that appear "tabbed" to right.
In the grub.conf file I've set mtrr:3 according to this guide.
To be honest I'm a little bit confused about this issue.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
