* [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size v2
@ 2008-09-28 3:26 Yinghai Lu
2008-09-28 5:58 ` Yinghai Lu
0 siblings, 1 reply; 4+ messages in thread
From: Yinghai Lu @ 2008-09-28 3:26 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Andrew Morton
Cc: linux-kernel, Yinghai Lu
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 - %016lx\n",
- hole_basek<<10,
- (hole_basek + hole_sizek)<<10);
- state->reg = range_to_mtrr(state->reg, hole_basek,
- hole_sizek,
- MTRR_TYPE_UNCACHABLE);
+
+ /* hole size should be less than half of range0 size */
+ if (hole_sizek > (range0_sizek >> 1) &&
+ range0_sizek >= chunk_sizek) {
+ range0_sizek -= chunk_sizek;
+ second_sizek = 0;
+ hole_sizek = 0;
+
+ goto second_try;
}
- } else {
+ }
+
+ 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);
+ }
+
+ if (range0_sizek < state->range_sizek) {
/* need to handle left over */
range_sizek = state->range_sizek - range0_sizek;
- if (range_sizek) {
- if (debug_print)
- printk(KERN_DEBUG "range: %016lx - %016lx\n",
- range_basek<<10,
- (range_basek + range_sizek)<<10);
- state->reg = range_to_mtrr(state->reg, range_basek,
- range_sizek,
- MTRR_TYPE_WRBACK);
- }
+ if (debug_print)
+ printk(KERN_DEBUG "range: %016lx - %016lx\n",
+ range_basek<<10,
+ (range_basek + range_sizek)<<10);
+ state->reg = range_to_mtrr(state->reg, range_basek,
+ range_sizek, MTRR_TYPE_WRBACK);
+ }
+
+ if (hole_sizek) {
+ hole_basek = range_basek - hole_sizek - second_sizek;
+ if (debug_print)
+ printk(KERN_DEBUG "hole: %016lx - %016lx\n",
+ hole_basek<<10,
+ (hole_basek + hole_sizek)<<10);
+ state->reg = range_to_mtrr(state->reg, hole_basek,
+ hole_sizek, MTRR_TYPE_UNCACHABLE);
}
return second_sizek;
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size v2
2008-09-28 3:26 [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size v2 Yinghai Lu
@ 2008-09-28 5:58 ` Yinghai Lu
2008-09-28 7:13 ` Ingo Molnar
0 siblings, 1 reply; 4+ messages in thread
From: Yinghai Lu @ 2008-09-28 5:58 UTC (permalink / raw)
To: Dylan Taft, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
Andrew Morton
Cc: linux-kernel, Yinghai Lu
On Sat, Sep 27, 2008 at 8:26 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> 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>
>
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size v2
2008-09-28 5:58 ` Yinghai Lu
@ 2008-09-28 7:13 ` Ingo Molnar
2008-09-28 9:10 ` Yinghai Lu
0 siblings, 1 reply; 4+ messages in thread
From: Ingo Molnar @ 2008-09-28 7:13 UTC (permalink / raw)
To: Yinghai Lu
Cc: Dylan Taft, Thomas Gleixner, H. Peter Anvin, Andrew Morton,
linux-kernel, Yinghai Lu
* Yinghai Lu <yinghai@kernel.org> wrote:
> On Sat, Sep 27, 2008 at 8:26 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> > 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>
> >
>
> Dylan,
>
> please try tip/master after Ingo put this patch into it...
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size v2
2008-09-28 7:13 ` Ingo Molnar
@ 2008-09-28 9:10 ` Yinghai Lu
0 siblings, 0 replies; 4+ messages in thread
From: Yinghai Lu @ 2008-09-28 9:10 UTC (permalink / raw)
To: Ingo Molnar, Gabriel C
Cc: Dylan Taft, Thomas Gleixner, H. Peter Anvin, Andrew Morton,
linux-kernel
On Sun, Sep 28, 2008 at 12:13 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Yinghai Lu <yinghai@kernel.org> wrote:
>
>> On Sat, Sep 27, 2008 at 8:26 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>> > 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>
>> >
>>
>> Dylan,
>>
>> please try tip/master after Ingo put this patch into it...
>
> 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.
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-09-28 9:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-28 3:26 [PATCH] x86: mtrr_cleanup hole size should be less than half of chunk_size v2 Yinghai Lu
2008-09-28 5:58 ` Yinghai Lu
2008-09-28 7:13 ` Ingo Molnar
2008-09-28 9:10 ` Yinghai Lu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.