LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices



Reply
 
Search this Thread
Old 06-16-2010, 12:32 AM   #1
rfernandez
Member
 
Registered: Mar 2010
Location: Brazil
Distribution: Slackware64
Posts: 264

Rep: Reputation: 40
What is "MTRR Cleanup spare reg num" About?


Hi, guys.

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.

Some info:

Code:
$ cat /proc/mtrr
reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x07f700000 ( 2039MB), size=    1MB, count=1: uncachable
reg02: base=0x07f800000 ( 2040MB), size=    8MB, count=1: uncachable
reg03: base=0x0e0000000 ( 3584MB), size=  256MB, count=1: write-combining
Kernel config:
Code:
[*]   MTRR cleanup support
(1)     MTRR cleanup enable value (0-1)
(1)     MTRR cleanup spare reg num (0-7)
So, I'm asking to you if you could help me understand this feature and to know what value to select at the "MTRR cleanup spare reg num".

Thanks in advance.
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 06-17-2010, 09:51 AM   #2
business_kid
Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 6,617

Rep: Reputation: 585Reputation: 585Reputation: 585Reputation: 585Reputation: 585Reputation: 585
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.
 
Old 06-17-2010, 12:28 PM   #3
rfernandez
Member
 
Registered: Mar 2010
Location: Brazil
Distribution: Slackware64
Posts: 264

Original Poster
Rep: Reputation: 40
Hi, business_kid, and thanks for your answer.

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.
 
Old 06-28-2010, 09:56 AM   #4
rfernandez
Member
 
Registered: Mar 2010
Location: Brazil
Distribution: Slackware64
Posts: 264

Original Poster
Rep: Reputation: 40
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.
 
2 members found this post helpful.
Old 09-21-2010, 07:38 AM   #5
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
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.
 
Old 09-22-2010, 03:26 AM   #6
business_kid
Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 6,617

Rep: Reputation: 585Reputation: 585Reputation: 585Reputation: 585Reputation: 585Reputation: 585
@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?
 
Old 09-22-2010, 05:59 AM   #7
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
You don't always use 5. For example, here you would use 5, because 5 registers are not being used:

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
Here you would use 4:

Code:
MTRR variable ranges enabled:
  0 base 000000000 mask F80000000 write-back
  1 base 07EF00000 mask FFFF00000 uncachable
  2 base 07F000000 mask FFF000000 uncachable
  3 disabled
  4 disabled
  5 disabled
  6 disabled
This is the output of dmesg.

I don't know if it makes much difference if PAT is enabled:

Code:
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
 
Old 09-23-2010, 03:21 AM   #8
rfernandez
Member
 
Registered: Mar 2010
Location: Brazil
Distribution: Slackware64
Posts: 264

Original Poster
Rep: Reputation: 40
Hi, guys. Sorry for the late reply.

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.
 
1 members found this post helpful.
Old 09-24-2010, 03:38 AM   #9
business_kid
Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 6,617

Rep: Reputation: 585Reputation: 585Reputation: 585Reputation: 585Reputation: 585Reputation: 585
Quote:
The instructions on "how to mange mtrr registers" are under the ./Documentation/x86/mtrr.txt on the linux-kernel source code.
@rfernandez:
Thanks for that. I'll put it on the list of things to be done
 
Old 12-01-2011, 01:01 PM   #10
fbcyborg
LQ Newbie
 
Registered: May 2010
Posts: 17

Rep: Reputation: 0
Hello,

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:
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
For that reason I cannot determine how many registers are free.

The only things I can see are the following:
Code:
reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c0000000 ( 3072MB), size=  256MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size=  512MB, count=1: write-back
reg04: base=0x120000000 ( 4608MB), size=  256MB, count=1: write-back
reg05: base=0x0fb000000 ( 4016MB), size=   16MB, count=1: write-combining
As regard my CPU, it supports both mtrr and pat, so they are enabled in the kernel configuration.

Another strange fact is that I cannot see any line like this:
Code:
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
As opposite, prior enabling the pat support, I could see:
Code:
NVRM: PAT configuration unsupported, falling back to MTRRs.
This no longer appears, since I've enabled PAT in the kernel today.

By the way: I use gentoo-sources-3.1.3 x86_64.

Thanks
 
Old 12-01-2011, 01:48 PM   #11
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
I'm not really sure about it, but I do know that PAT should override MTRR, so enabling it should be enough.
http://en.wikipedia.org/wiki/Mtrr
 
Old 12-01-2011, 02:41 PM   #12
fbcyborg
LQ Newbie
 
Registered: May 2010
Posts: 17

Rep: Reputation: 0
Thank you for replying.

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.
 
Old 12-03-2011, 08:27 AM   #13
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Ok, I messed with the kernel boot parameter 'mtrr_spare_reg_nr=' and found something out:

For values 0-4, I get:

Code:
MTRR default type: uncachable
MTRR fixed ranges enabled:
  00000-9FFFF write-back
  A0000-BFFFF uncachable
  C0000-DFFFF write-protect
  E0000-FFFFF uncachable
MTRR variable ranges enabled:
  0 base 000000000 mask F80000000 write-back
  1 base 07EF00000 mask FFFF00000 uncachable
  2 base 07F000000 mask FFF000000 uncachable
  3 disabled
  4 disabled
  5 disabled
  6 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 2031MB, range: 1MB, type UC
reg 2, base: 2032MB, range: 16MB, type UC
total RAM covered: 2031M
Found optimal setting for mtrr clean up
 gran_size: 64K 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 0G
New variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 2031MB, range: 1MB, type UC
reg 2, base: 2032MB, range: 16MB, type UC
For values 5-6, I get:

Code:
MTRR default type: uncachable
MTRR fixed ranges enabled:
  00000-9FFFF write-back
  A0000-BFFFF uncachable
  C0000-DFFFF write-protect
  E0000-FFFFF uncachable
MTRR variable ranges enabled:
  0 base 000000000 mask F80000000 write-back
  1 base 07EF00000 mask FFFF00000 uncachable
  2 base 07F000000 mask FFF000000 uncachable
  3 disabled
  4 disabled
  5 disabled
  6 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 2031MB, range: 1MB, type UC
reg 2, base: 2032MB, range: 16MB, type UC
total RAM covered: 2031M
 gran_size: 64K 	chunk_size: 64K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 128K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 256K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 512K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 1M 	num_reg: 7  	lose cover RAM: 7M
*BAD*gran_size: 64K 	chunk_size: 2M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 64K 	chunk_size: 4M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 64K 	chunk_size: 8M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 64K 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: -1M
 gran_size: 64K 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 64M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 128M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 512M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 2G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 128K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 256K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 512K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 1M 	num_reg: 7  	lose cover RAM: 7M
*BAD*gran_size: 128K 	chunk_size: 2M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 128K 	chunk_size: 4M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 128K 	chunk_size: 8M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 128K 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: -1M
 gran_size: 128K 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 64M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 128M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 512M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 2G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 256K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 256K 	chunk_size: 512K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 256K 	chunk_size: 1M 	num_reg: 7  	lose cover RAM: 7M
*BAD*gran_size: 256K 	chunk_size: 2M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 256K 	chunk_size: 4M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 256K 	chunk_size: 8M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 256K 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: -1M
 gran_size: 256K 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 64M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 128M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 512M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 2G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 512K 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 512K 	chunk_size: 1M 	num_reg: 7  	lose cover RAM: 7M
*BAD*gran_size: 512K 	chunk_size: 2M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 512K 	chunk_size: 4M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 512K 	chunk_size: 8M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 512K 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: -1M
 gran_size: 512K 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 64M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 128M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 512M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 2G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 1M 	num_reg: 7  	lose cover RAM: 7M
*BAD*gran_size: 1M 	chunk_size: 2M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 1M 	chunk_size: 4M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 1M 	chunk_size: 8M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 1M 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: -1M
 gran_size: 1M 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 64M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 128M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 512M 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 2G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 2M 	chunk_size: 2M 	num_reg: 7  	lose cover RAM: 7M
*BAD*gran_size: 2M 	chunk_size: 4M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 2M 	chunk_size: 8M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 2M 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: -1M
 gran_size: 2M 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 64M 	num_reg: 3  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 128M 	num_reg: 3  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 512M 	num_reg: 3  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 2G 	num_reg: 3  	lose cover RAM: 1M
 gran_size: 4M 	chunk_size: 4M 	num_reg: 7  	lose cover RAM: 7M
*BAD*gran_size: 4M 	chunk_size: 8M 	num_reg: 7  	lose cover RAM: -1M
*BAD*gran_size: 4M 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: -1M
 gran_size: 4M 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 64M 	num_reg: 3  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 128M 	num_reg: 3  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 512M 	num_reg: 3  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 2G 	num_reg: 3  	lose cover RAM: 3M
 gran_size: 8M 	chunk_size: 8M 	num_reg: 7  	lose cover RAM: 7M
*BAD*gran_size: 8M 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: -1M
 gran_size: 8M 	chunk_size: 32M 	num_reg: 3  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 64M 	num_reg: 3  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 128M 	num_reg: 3  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 512M 	num_reg: 3  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 2G 	num_reg: 3  	lose cover RAM: 7M
 gran_size: 16M 	chunk_size: 16M 	num_reg: 6  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 32M 	num_reg: 6  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 64M 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 128M 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 256M 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 512M 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 1G 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 32M 	chunk_size: 32M 	num_reg: 6  	lose cover RAM: 15M
 gran_size: 32M 	chunk_size: 64M 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 32M 	chunk_size: 128M 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 32M 	chunk_size: 256M 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 32M 	chunk_size: 512M 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 32M 	chunk_size: 1G 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 32M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 64M 	chunk_size: 64M 	num_reg: 5  	lose cover RAM: 47M
 gran_size: 64M 	chunk_size: 128M 	num_reg: 2  	lose cover RAM: 47M
 gran_size: 64M 	chunk_size: 256M 	num_reg: 2  	lose cover RAM: 47M
 gran_size: 64M 	chunk_size: 512M 	num_reg: 2  	lose cover RAM: 47M
 gran_size: 64M 	chunk_size: 1G 	num_reg: 2  	lose cover RAM: 47M
 gran_size: 64M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 47M
 gran_size: 128M 	chunk_size: 128M 	num_reg: 4  	lose cover RAM: 111M
 gran_size: 128M 	chunk_size: 256M 	num_reg: 2  	lose cover RAM: 111M
 gran_size: 128M 	chunk_size: 512M 	num_reg: 2  	lose cover RAM: 111M
 gran_size: 128M 	chunk_size: 1G 	num_reg: 2  	lose cover RAM: 111M
 gran_size: 128M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 111M
 gran_size: 256M 	chunk_size: 256M 	num_reg: 3  	lose cover RAM: 239M
 gran_size: 256M 	chunk_size: 512M 	num_reg: 2  	lose cover RAM: 239M
 gran_size: 256M 	chunk_size: 1G 	num_reg: 2  	lose cover RAM: 239M
 gran_size: 256M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 239M
 gran_size: 512M 	chunk_size: 512M 	num_reg: 2  	lose cover RAM: 495M
 gran_size: 512M 	chunk_size: 1G 	num_reg: 2  	lose cover RAM: 495M
 gran_size: 512M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 495M
 gran_size: 1G 	chunk_size: 1G 	num_reg: 1  	lose cover RAM: 1007M
 gran_size: 1G 	chunk_size: 2G 	num_reg: 1  	lose cover RAM: 1007M
 gran_size: 2G 	chunk_size: 2G 	num_reg: 0  	lose cover RAM: 2031M
mtrr_cleanup: can not find optimal value
please specify mtrr_gran_size/mtrr_chunk_size
You can draw your own conclusions or try it yourself.
 
Old 12-04-2011, 08:52 AM   #14
fbcyborg
LQ Newbie
 
Registered: May 2010
Posts: 17

Rep: Reputation: 0
Thanks,

actually I've never tried to pass the "mtrr_spare_reg_nr=" parameter to the kernel line in grub.
I have to do some test.
 
  


Reply

Tags
build, cleanup, custom, mtrr


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
warning: dynamic sections for "xxx/XX.so.num" is not at the expected address? shichangyou2 Linux - Software 1 04-27-2010 09:47 PM
RAID 5 with mdadm "spare" and "active sync" confusion ufmale Linux - Server 1 12-08-2007 11:31 AM
Setting num lock to "on" at boot or log in. ToothlessRebel Linux - Newbie 8 05-30-2006 12:46 PM
want full description of "echo num > / path/...." zameer_india Linux - Newbie 5 01-08-2005 04:10 AM
mysql "max spare servers"???? bulliver Linux - Software 6 08-17-2003 03:25 PM


All times are GMT -5. The time now is 10:12 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration