Re: [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size v2

Previous thread: [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size by Yinghai Lu on Saturday, September 27, 2008 - 8:04 pm. (1 message)

Next thread: Subject:[PATCH] PCIE: use PCI_EXT_CAP_NEXT to traverse PCIE extended capability list. by qingtao.cao on Saturday, September 27, 2008 - 8:58 pm. (1 message)
From: Yinghai Lu
Date: Saturday, September 27, 2008 - 8:26 pm

v2: should check with half of range0 size instead of chunk_size

So don't have silly big hole.

in hpa's case we could auto detect instead of adding mtrr_chunk_size in command line

Ingo, please consider to squash this one to previous one
|  commit 2313c2793d290a8cc37c428f8622c53f3fe1d6dc
|  Author: Yinghai Lu <yhlu.kernel@gmail.com>
|  Date:   Sat Sep 27 00:30:08 2008 -0700
|
|      x86: mtrr_cleanup optimization, v2

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 arch/x86/kernel/cpu/mtrr/main.c |   74 +++++++++++++++++++++++-----------------
 1 file changed, 43 insertions(+), 31 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
@@ -992,22 +992,17 @@ range_to_mtrr_with_hole(struct var_mtrr_
 	/* only cut back, when it is not the last */
 	if (sizek) {
 		while (range0_basek + range0_sizek > (basek + sizek)) {
-			range0_sizek -= chunk_sizek;
+			if (range0_sizek >= chunk_sizek)
+				range0_sizek -= chunk_sizek;
+			else
+				range0_sizek = 0;
+
 			if (!range0_sizek)
 				break;
 		}
 	}
 
-	if (range0_sizek) {
-		if (debug_print)
-			printk(KERN_DEBUG "range0: %016lx - %016lx\n",
-				range0_basek<<10,
-				(range0_basek + range0_sizek)<<10);
-		state->reg = range_to_mtrr(state->reg, range0_basek,
-				range0_sizek, MTRR_TYPE_WRBACK);
-
-	}
-
+second_try:
 	range_basek = range0_basek + range0_sizek;
 
 	/* one hole in the middle */
@@ -1015,33 +1010,50 @@ range_to_mtrr_with_hole(struct var_mtrr_
 		second_sizek = range_basek - basek;
 
 	if (range0_sizek > state->range_sizek) {
-		unsigned long hole_basek, hole_sizek;
 
 		/* one hole in middle or at end */
 		hole_sizek = range0_sizek - state->range_sizek - second_sizek;
-		if (hole_sizek) {
-			hole_basek = range_basek - hole_sizek - second_sizek;
-			if (debug_print)
-				printk(KERN_DEBUG "hole: %016lx - ...
From: Yinghai Lu
Date: Saturday, September 27, 2008 - 10:58 pm

Dylan,

please try tip/master after Ingo put this patch into it...

from
reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg02: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
reg03: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg04: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg05: base=0xc7e00000 (3198MB), size=   2MB: uncachable, count=1
reg06: base=0xc8000000 (3200MB), size= 128MB: uncachable, count=1

you should get
Found optimal setting for mtrr clean up
gran_size: 1M   chunk_size: 256M        num_reg: 7      lose RAM: 0M
range0: 0000000000000000 - 00000000d0000000
Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
hole: 00000000c7e00000 - 00000000d0000000
Setting variable MTRR 3, base: 3198MB, range: 2MB, type UC
Setting variable MTRR 4, base: 3200MB, range: 128MB, type UC
rangeX: 0000000100000000 - 0000000130000000
Setting variable MTRR 5, base: 4096MB, range: 512MB, type WB
Setting variable MTRR 6, base: 4608MB, range: 256MB, type WB


with mtrr_spare_reg_nr=2 you should get
Found optimal setting for mtrr clean up
gran_size: 1M   chunk_size: 4M        num_reg: 6      lose RAM: 0M
range0: 0000000000000000 - 00000000c8000000
Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 128MB, type WB
hole: 00000000c7e00000 - 00000000c8000000
Setting variable MTRR 3, base: 3198MB, range: 2MB, type UC
rangeX: 0000000100000000 - 0000000130000000
Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
--

From: Ingo Molnar
Date: Sunday, September 28, 2008 - 12:13 am

applied to tip/x86/mtrr, thanks Yinghai! I've also propagated it to 
tip/master and pushed it out, so Dylan could do a one-stop testing of 
tip/master.

	Ingo
--

From: Yinghai Lu
Date: Sunday, September 28, 2008 - 2:10 am

Gabriel, can you check tip/mater too?
http://people.redhat.com/mingo/tip.git/readme.txt

from
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size=  64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1

you should get
Found optimal setting for mtrr clean up
gran_size: 1M   chunk_size: 16M         num_reg: 7      lose RAM: 0M
range0: 0000000000000000 - 00000000d0000000
Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
hole: 00000000cf600000 - 00000000cf800000
Setting variable MTRR 3, base: 3318MB, range: 2MB, type UC
rangeX: 0000000100000000 - 000000012c000000
Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
Setting variable MTRR 5, base: 4608MB, range: 128MB, type WB
Setting variable MTRR 6, base: 4736MB, range: 64MB, type WB

instead of

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcfe00000 (3326MB), size=   2MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg05: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
reg06: base=0x12c000000 (4800MB), size=  64MB: uncachable, count=1

YH
--

Previous thread: [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size by Yinghai Lu on Saturday, September 27, 2008 - 8:04 pm. (1 message)

Next thread: Subject:[PATCH] PCIE: use PCI_EXT_CAP_NEXT to traverse PCIE extended capability list. by qingtao.cao on Saturday, September 27, 2008 - 8:58 pm. (1 message)