2008-01-21 06:51:44

by Yinghai Lu

[permalink] [raw]
Subject: [PATCH] x86_32: trim memory by updating e820 v2

[PATCH] x86_32: trim memory by updating e820 v2

when mtrr is not covering all e820 table, need to trim the ram, need to update e820

reuse some code for x86_64

here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early

compiled test only, need someone test it


Index: linux-2.6/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common.c
+++ linux-2.6/arch/x86/kernel/cpu/common.c
@@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se
/*
* This does the hard work of actually picking apart the CPU stuff...
*/
-void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
{
- int i;

- c->loops_per_jiffy = loops_per_jiffy;
c->x86_cache_size = -1;
c->x86_vendor = X86_VENDOR_UNKNOWN;
c->cpuid_level = -1; /* CPUID not detected */
@@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuin

if (this_cpu->c_identify)
this_cpu->c_identify(c);
+}

+void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+{
+ int i;
+
+ c->loops_per_jiffy = loops_per_jiffy;
+ early_identify_cpu(c);
/*
* Vendor-specific initialization. In this section we
* canonicalize the feature flags, meaning if there are
@@ -485,7 +490,6 @@ void __init identify_boot_cpu(void)
identify_cpu(&boot_cpu_data);
sysenter_setup();
enable_sep_cpu();
- mtrr_bp_init();
}

void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
Index: linux-2.6/arch/x86/kernel/setup_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup_32.c
+++ linux-2.6/arch/x86/kernel/setup_32.c
@@ -49,6 +49,7 @@

#include <video/edid.h>

+#include <asm/mtrr.h>
#include <asm/apic.h>
#include <asm/e820.h>
#include <asm/mpspec.h>
@@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = virt_to_phys(&__bss_start);
bss_resource.end = virt_to_phys(&__bss_stop)-1;

+ early_identify_cpu(&boot_cpu_data);
parse_early_param();

if (user_defined_memmap) {
@@ -762,6 +764,12 @@ void __init setup_arch(char **cmdline_p)

max_low_pfn = setup_memory();

+ /* update e820 for memory not covered by WB MTRRs */
+ mtrr_bp_init();
+ if (mtrr_trim_uncached_memory(max_pfn)) {
+ max_low_pfn = setup_memory();
+ }
+
#ifdef CONFIG_VMI
/*
* Must be after max_low_pfn is determined, and before kernel
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
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_
.resume = mtrr_restore,
};

-#ifdef CONFIG_X86_64
static int disable_mtrr_trim;

static int __init disable_mtrr_trim_setup(char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns

return 0;
}
-#endif

/**
* mtrr_bp_init - initialize mtrrs on the boot CPU
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters.
See drivers/char/README.epca and
Documentation/digiepca.txt.

- disable_mtrr_trim [X86-64, Intel only]
+ disable_mtrr_trim [X86, Intel and AMD only]
By default the kernel will trim any uncacheable
memory out of your available memory pool based on
MTRR settings. This parameter disables that behavior,
Index: linux-2.6/include/asm-x86/processor.h
===================================================================
--- linux-2.6.orig/include/asm-x86/processor.h
+++ linux-2.6/include/asm-x86/processor.h
@@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_

void cpu_detect(struct cpuinfo_x86 *c);

+extern void early_identify_cpu(struct cpuinfo_x86 *);
extern void identify_cpu(struct cpuinfo_x86 *);
extern void identify_boot_cpu(void);
extern void identify_secondary_cpu(struct cpuinfo_x86 *);
Index: linux-2.6/arch/x86/kernel/e820_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820_32.c
+++ linux-2.6/arch/x86/kernel/e820_32.c
@@ -827,3 +827,14 @@ static int __init parse_memmap(char *arg
return 0;
}
early_param("memmap", parse_memmap);
+void __init update_e820(void)
+{
+ u8 nr_map;
+
+ nr_map = e820.nr_map;
+ if (sanitize_e820_map(e820.map, &nr_map))
+ return;
+ e820.nr_map = nr_map;
+ printk(KERN_INFO "modified physical RAM map:\n");
+ print_memory_map("modified");
+}
Index: linux-2.6/include/asm-x86/e820_32.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820_32.h
+++ linux-2.6/include/asm-x86/e820_32.h
@@ -19,6 +19,7 @@
#ifndef __ASSEMBLY__

extern struct e820map e820;
+extern void update_e820(void);

extern int e820_all_mapped(u64 start, u64 end, unsigned type);
extern int e820_any_mapped(u64 start, u64 end, unsigned type);
@@ -29,6 +30,8 @@ extern int is_memory_all_valid(u64 start
extern int is_memory_all_reserved(u64 start, u64 end);
extern void find_max_pfn(void);
extern void register_bootmem_low_pages(unsigned long max_low_pfn);
+extern void add_memory_region(unsigned long long start,
+ unsigned long long size, int type);
extern void e820_register_memory(void);
extern void limit_regions(unsigned long long size);
extern void print_memory_map(char *who);
--- a/arch/x86/kernel/setup_64.c 2008-01-20 22:00:46.000000000 -0800
+++ b/arch/x86/kernel/setup_64.c 2008-01-20 22:01:21.000000000 -0800
@@ -158,8 +158,6 @@
.flags = IORESOURCE_RAM,
};

-static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c);
-
#ifdef CONFIG_PROC_VMCORE
/* elfcorehdr= specifies the location of elf core header
* stored by the crashed kernel. This option will be passed
@@ -891,7 +889,7 @@
/* Do some early cpuid on the boot CPU to get some parameter that are
needed before check_bugs. Everything advanced is in identify_cpu
below. */
-static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
{
u32 tfms, xlvl;


2008-01-21 16:30:52

by Jesse Barnes

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2

On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
> [PATCH] x86_32: trim memory by updating e820 v2
>
> when mtrr is not covering all e820 table, need to trim the ram, need to
> update e820
>
> reuse some code for x86_64
>
> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
>
> compiled test only, need someone test it

I like this approach too. So as long as the E820 modification method works
(i.e. we have some testers, maybe Justin can give it a try), you can add

Signed-off-by: Jesse Barnes <[email protected]>

or

Acked-by: Jesse Barnes <[email protected]>

as appropriate too.

Thanks,
Jesse

2008-01-21 19:14:18

by Justin Piszcz

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2



On Mon, 21 Jan 2008, Jesse Barnes wrote:

> On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
>> [PATCH] x86_32: trim memory by updating e820 v2
>>
>> when mtrr is not covering all e820 table, need to trim the ram, need to
>> update e820
>>
>> reuse some code for x86_64
>>
>> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
>>
>> compiled test only, need someone test it
>
> I like this approach too. So as long as the E820 modification method works
> (i.e. we have some testers, maybe Justin can give it a try), you can add
>
> Signed-off-by: Jesse Barnes <[email protected]>
>
> or
>
> Acked-by: Jesse Barnes <[email protected]>
>
> as appropriate too.
>
> Thanks,
> Jesse
>

Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2
^^

I run x86_64 btw-- if there is a kernel.patch for x86_64 please let me
know and I can test, thanks.

Justin.

2008-01-21 20:03:19

by Yinghai Lu

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2

On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
>
> On Mon, 21 Jan 2008, Jesse Barnes wrote:
>
> > On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
> >> [PATCH] x86_32: trim memory by updating e820 v2
> >>
> >> when mtrr is not covering all e820 table, need to trim the ram, need to
> >> update e820
> >>
> >> reuse some code for x86_64
> >>
> >> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
> >>
> >> compiled test only, need someone test it
> >
> > I like this approach too. So as long as the E820 modification method works
> > (i.e. we have some testers, maybe Justin can give it a try), you can add
> >
> > Signed-off-by: Jesse Barnes <[email protected]>
> >
> > or
> >
> > Acked-by: Jesse Barnes <[email protected]>
> >
> > as appropriate too.
> >
> > Thanks,
> > Jesse
> >
>
> Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2
> ^^
>
> I run x86_64 btw-- if there is a kernel.patch for x86_64 please let me
> know and I can test, thanks.

please get x86.git

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
#--------------{ x86.git instructions }---------->
# Add Linus's tree as a remote
git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

# Add Ingo's tree as a remote
git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

# With that setup, just run the following to get any changes you
# don't have. It will also notice any new branches Ingo/Linus
# add to their repo. Look in .git/config afterwards, the format
# to add new remotes is easy to figure out.
git remote update
#-------------------------
git merge x86/master
git merge x86/mm

and apply

[PATCH] x86_64: check if Tom2 is enabled
http://lkml.org/lkml/2008/1/21/20
[PATCH] x86_64: update e820 instead of updating end_pfn v3
http://lkml.org/lkml/2008/1/21/19
[PATCH] x86_32: trim memory by updating e820 v2
http://lkml.org/lkml/2008/1/21/18

YH

2008-01-21 21:37:23

by Justin Piszcz

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2



On Mon, 21 Jan 2008, Yinghai Lu wrote:

> On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
> please get x86.git
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> cd linux-2.6
> #--------------{ x86.git instructions }---------->
> # Add Linus's tree as a remote
> git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> # Add Ingo's tree as a remote
> git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>
> # With that setup, just run the following to get any changes you
> # don't have. It will also notice any new branches Ingo/Linus
> # add to their repo. Look in .git/config afterwards, the format
> # to add new remotes is easy to figure out.
> git remote update
> #-------------------------
> git merge x86/master
> git merge x86/mm
>
> and apply
>
> [PATCH] x86_64: check if Tom2 is enabled
> http://lkml.org/lkml/2008/1/21/20
> [PATCH] x86_64: update e820 instead of updating end_pfn v3
> http://lkml.org/lkml/2008/1/21/19
> [PATCH] x86_32: trim memory by updating e820 v2
> http://lkml.org/lkml/2008/1/21/18
>
> YH
>

Thanks, I am all patched up and ready to test, unfortunately one of my disks
in my RAID 1 just died, I already filled out the advanced replacement form,
I will test when I receive the replacement disk.

p34:~# lilo
Fatal: Not all RAID-1 disks are active; use '-H' to install to active disks only
p34:~# lilo -H
Warning: Partial RAID-1 install on active disks only; booting is not failsafe

Warning: Faulty disk in RAID-1 array; boot with caution!!
Fatal: Unusual RAID bios device code: 0xFF
p34:~#

Don't feel like mucking up my system at the moment.

Justin.

2008-01-22 16:52:14

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2


* Yinghai Lu <[email protected]> wrote:

> [PATCH] x86_32: trim memory by updating e820 v2
>
> when mtrr is not covering all e820 table, need to trim the ram, need
> to update e820
>
> reuse some code for x86_64
>
> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init
> early
>
> compiled test only, need someone test it

i picked up the patch below, and it crashes with:

Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
------------[ cut here ]------------
kernel BUG at arch/x86/mm/pageattr_32.c:327!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC

Pid: 0, comm: swapper Not tainted (2.6.24-rc8 #15)
EIP: 0060:[<c0116a3f>] EFLAGS: 00010297 CPU: 0
EIP is at kernel_map_pages+0x52/0xb3

config and bootlog attached as well.

Ingo

------------------>
Subject: x86_32: trim memory by updating e820
From: Yinghai Lu <[email protected]>

when mtrr is not covering all e820 table, need to trim the ram, need to
update e820

reuse some code for x86_64

here need to add early_identify_cpu for x86_32, and move mtrr_bp_init
early

compiled test only, need someone test it

Signed-off-by: Ingo Molnar <[email protected]>
---
Documentation/kernel-parameters.txt | 2 +-
arch/x86/kernel/cpu/common.c | 12 ++++++++----
arch/x86/kernel/cpu/mtrr/main.c | 2 --
arch/x86/kernel/e820_32.c | 11 +++++++++++
arch/x86/kernel/setup_32.c | 7 +++++++
arch/x86/kernel/setup_64.c | 4 +---
include/asm-x86/e820_32.h | 3 +++
include/asm-x86/processor.h | 1 +
8 files changed, 32 insertions(+), 10 deletions(-)

Index: linux-x86.q/Documentation/kernel-parameters.txt
===================================================================
--- linux-x86.q.orig/Documentation/kernel-parameters.txt
+++ linux-x86.q/Documentation/kernel-parameters.txt
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters.
See drivers/char/README.epca and
Documentation/digiepca.txt.

- disable_mtrr_trim [X86-64, Intel only]
+ disable_mtrr_trim [X86, Intel and AMD only]
By default the kernel will trim any uncacheable
memory out of your available memory pool based on
MTRR settings. This parameter disables that behavior,
Index: linux-x86.q/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/cpu/common.c
+++ linux-x86.q/arch/x86/kernel/cpu/common.c
@@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se
/*
* This does the hard work of actually picking apart the CPU stuff...
*/
-void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
{
- int i;

- c->loops_per_jiffy = loops_per_jiffy;
c->x86_cache_size = -1;
c->x86_vendor = X86_VENDOR_UNKNOWN;
c->cpuid_level = -1; /* CPUID not detected */
@@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuin

if (this_cpu->c_identify)
this_cpu->c_identify(c);
+}

+void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+{
+ int i;
+
+ c->loops_per_jiffy = loops_per_jiffy;
+ early_identify_cpu(c);
/*
* Vendor-specific initialization. In this section we
* canonicalize the feature flags, meaning if there are
@@ -485,7 +490,6 @@ void __init identify_boot_cpu(void)
identify_cpu(&boot_cpu_data);
sysenter_setup();
enable_sep_cpu();
- mtrr_bp_init();
}

void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
Index: linux-x86.q/arch/x86/kernel/cpu/mtrr/main.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/cpu/mtrr/main.c
+++ linux-x86.q/arch/x86/kernel/cpu/mtrr/main.c
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_
.resume = mtrr_restore,
};

-#ifdef CONFIG_X86_64
static int disable_mtrr_trim;

static int __init disable_mtrr_trim_setup(char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns

return 0;
}
-#endif

/**
* mtrr_bp_init - initialize mtrrs on the boot CPU
Index: linux-x86.q/arch/x86/kernel/e820_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/e820_32.c
+++ linux-x86.q/arch/x86/kernel/e820_32.c
@@ -749,3 +749,14 @@ static int __init parse_memmap(char *arg
return 0;
}
early_param("memmap", parse_memmap);
+void __init update_e820(void)
+{
+ u8 nr_map;
+
+ nr_map = e820.nr_map;
+ if (sanitize_e820_map(e820.map, &nr_map))
+ return;
+ e820.nr_map = nr_map;
+ printk(KERN_INFO "modified physical RAM map:\n");
+ print_memory_map("modified");
+}
Index: linux-x86.q/arch/x86/kernel/setup_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/setup_32.c
+++ linux-x86.q/arch/x86/kernel/setup_32.c
@@ -49,6 +49,7 @@

#include <video/edid.h>

+#include <asm/mtrr.h>
#include <asm/apic.h>
#include <asm/e820.h>
#include <asm/mpspec.h>
@@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = virt_to_phys(&__bss_start);
bss_resource.end = virt_to_phys(&__bss_stop)-1;

+ early_identify_cpu(&boot_cpu_data);
parse_early_param();

if (user_defined_memmap) {
@@ -762,6 +764,11 @@ void __init setup_arch(char **cmdline_p)

max_low_pfn = setup_memory();

+ /* update e820 for memory not covered by WB MTRRs */
+ mtrr_bp_init();
+ if (mtrr_trim_uncached_memory(max_pfn))
+ max_low_pfn = setup_memory();
+
#ifdef CONFIG_VMI
/*
* Must be after max_low_pfn is determined, and before kernel
Index: linux-x86.q/arch/x86/kernel/setup_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/setup_64.c
+++ linux-x86.q/arch/x86/kernel/setup_64.c
@@ -157,8 +157,6 @@ static struct resource bss_resource = {
.flags = IORESOURCE_RAM,
};

-static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c);
-
#ifdef CONFIG_PROC_VMCORE
/* elfcorehdr= specifies the location of elf core header
* stored by the crashed kernel. This option will be passed
@@ -890,7 +888,7 @@ struct cpu_model_info {
/* Do some early cpuid on the boot CPU to get some parameter that are
needed before check_bugs. Everything advanced is in identify_cpu
below. */
-static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
{
u32 tfms, xlvl;

Index: linux-x86.q/include/asm-x86/e820_32.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/e820_32.h
+++ linux-x86.q/include/asm-x86/e820_32.h
@@ -19,12 +19,15 @@
#ifndef __ASSEMBLY__

extern struct e820map e820;
+extern void update_e820(void);

extern int e820_all_mapped(unsigned long start, unsigned long end,
unsigned type);
extern int e820_any_mapped(u64 start, u64 end, unsigned type);
extern void find_max_pfn(void);
extern void register_bootmem_low_pages(unsigned long max_low_pfn);
+extern void add_memory_region(unsigned long long start,
+ unsigned long long size, int type);
extern void e820_register_memory(void);
extern void limit_regions(unsigned long long size);
extern void print_memory_map(char *who);
Index: linux-x86.q/include/asm-x86/processor.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/processor.h
+++ linux-x86.q/include/asm-x86/processor.h
@@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_

void cpu_detect(struct cpuinfo_x86 *c);

+extern void early_identify_cpu(struct cpuinfo_x86 *);
extern void identify_cpu(struct cpuinfo_x86 *);
extern void identify_boot_cpu(void);
extern void identify_secondary_cpu(struct cpuinfo_x86 *);


Attachments:
(No filename) (7.58 kB)
config (43.62 kB)
crash.log (9.73 kB)
Download all attachments

2008-01-23 00:17:29

by Yinghai Lu

[permalink] [raw]
Subject: [PATCH] x86_32: trim memory by updating e820 v3

[PATCH] x86_32: trim memory by updating e820 v3

when mtrr is not covering all e820 table, need to trim the ram, need to update e820

reuse some code for x86_64

here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early

need Justine to test with his special system with bug bios.

Signed-off-by: Yinghai Lu <[email protected]>

Index: linux-2.6/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common.c
+++ linux-2.6/arch/x86/kernel/cpu/common.c
@@ -278,6 +278,33 @@ void __init cpu_detect(struct cpuinfo_x8
c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8;
}
}
+static void __cpuinit early_get_cap(struct cpuinfo_x86 *c)
+{
+ u32 tfms, xlvl;
+ int ebx;
+
+ memset(&c->x86_capability, 0, sizeof c->x86_capability);
+ if (have_cpuid_p()) {
+ /* Intel-defined flags: level 0x00000001 */
+ if (c->cpuid_level >= 0x00000001) {
+ u32 capability, excap;
+ cpuid(0x00000001, &tfms, &ebx, &excap, &capability);
+ c->x86_capability[0] = capability;
+ c->x86_capability[4] = excap;
+ }
+
+ /* AMD-defined flags: level 0x80000001 */
+ xlvl = cpuid_eax(0x80000000);
+ if ((xlvl & 0xffff0000) == 0x80000000) {
+ if (xlvl >= 0x80000001) {
+ c->x86_capability[1] = cpuid_edx(0x80000001);
+ c->x86_capability[6] = cpuid_ecx(0x80000001);
+ }
+ }
+
+ }
+
+}

/* Do minimum CPU detection early.
Fields really needed: vendor, cpuid_level, family, model, mask, cache alignment.
@@ -306,6 +333,8 @@ static void __init early_cpu_detect(void
early_init_intel(c);
break;
}
+
+ early_get_cap(c);
}

static void __cpuinit generic_identify(struct cpuinfo_x86 * c)
@@ -485,7 +514,6 @@ void __init identify_boot_cpu(void)
identify_cpu(&boot_cpu_data);
sysenter_setup();
enable_sep_cpu();
- mtrr_bp_init();
}

void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
Index: linux-2.6/arch/x86/kernel/setup_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup_32.c
+++ linux-2.6/arch/x86/kernel/setup_32.c
@@ -49,6 +49,7 @@

#include <video/edid.h>

+#include <asm/mtrr.h>
#include <asm/apic.h>
#include <asm/e820.h>
#include <asm/mpspec.h>
@@ -762,6 +763,11 @@ void __init setup_arch(char **cmdline_p)

max_low_pfn = setup_memory();

+ /* update e820 for memory not covered by WB MTRRs */
+ mtrr_bp_init();
+ if (mtrr_trim_uncached_memory(max_pfn))
+ max_low_pfn = setup_memory();
+
#ifdef CONFIG_VMI
/*
* Must be after max_low_pfn is determined, and before kernel
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
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_
.resume = mtrr_restore,
};

-#ifdef CONFIG_X86_64
static int disable_mtrr_trim;

static int __init disable_mtrr_trim_setup(char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns

return 0;
}
-#endif

/**
* mtrr_bp_init - initialize mtrrs on the boot CPU
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters.
See drivers/char/README.epca and
Documentation/digiepca.txt.

- disable_mtrr_trim [X86-64, Intel only]
+ disable_mtrr_trim [X86, Intel and AMD only]
By default the kernel will trim any uncacheable
memory out of your available memory pool based on
MTRR settings. This parameter disables that behavior,
Index: linux-2.6/arch/x86/kernel/e820_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820_32.c
+++ linux-2.6/arch/x86/kernel/e820_32.c
@@ -749,3 +749,14 @@ static int __init parse_memmap(char *arg
return 0;
}
early_param("memmap", parse_memmap);
+void __init update_e820(void)
+{
+ u8 nr_map;
+
+ nr_map = e820.nr_map;
+ if (sanitize_e820_map(e820.map, &nr_map))
+ return;
+ e820.nr_map = nr_map;
+ printk(KERN_INFO "modified physical RAM map:\n");
+ print_memory_map("modified");
+}
Index: linux-2.6/include/asm-x86/e820_32.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820_32.h
+++ linux-2.6/include/asm-x86/e820_32.h
@@ -19,12 +19,15 @@
#ifndef __ASSEMBLY__

extern struct e820map e820;
+extern void update_e820(void);

extern int e820_all_mapped(unsigned long start, unsigned long end,
unsigned type);
extern int e820_any_mapped(u64 start, u64 end, unsigned type);
extern void find_max_pfn(void);
extern void register_bootmem_low_pages(unsigned long max_low_pfn);
+extern void add_memory_region(unsigned long long start,
+ unsigned long long size, int type);
extern void e820_register_memory(void);
extern void limit_regions(unsigned long long size);
extern void print_memory_map(char *who);

2008-01-23 03:44:00

by Yinghai Lu

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2

On Monday 21 January 2008 01:37:09 pm Justin Piszcz wrote:
>
> On Mon, 21 Jan 2008, Yinghai Lu wrote:
>
> > On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
> > please get x86.git
> >
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > cd linux-2.6
> > #--------------{ x86.git instructions }---------->
> > # Add Linus's tree as a remote
> > git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >
> > # Add Ingo's tree as a remote
> > git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
> >
> > # With that setup, just run the following to get any changes you
> > # don't have. It will also notice any new branches Ingo/Linus
> > # add to their repo. Look in .git/config afterwards, the format
> > # to add new remotes is easy to figure out.
> > git remote update
> > #-------------------------
> > git merge x86/master
> > git merge x86/mm
> >
> > and apply
> >
> > [PATCH] x86_64: check if Tom2 is enabled
> > http://lkml.org/lkml/2008/1/21/20
> > [PATCH] x86_64: update e820 instead of updating end_pfn v3
> > http://lkml.org/lkml/2008/1/21/19
> > [PATCH] x86_32: trim memory by updating e820 v2
> > http://lkml.org/lkml/2008/1/21/18
> >
> > YH
> >
>
> Thanks, I am all patched up and ready to test, unfortunately one of my disks
> in my RAID 1 just died, I already filled out the advanced replacement form,
> I will test when I receive the replacement disk.

please get x86.git and apply
[PATCH] x86_32: trim memory by updating e820 v3
http://lkml.org/lkml/2008/1/22/394

Ingo already put other two into the tree.

Thanks

YH

2008-01-26 00:01:54

by Justin Piszcz

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2



On Tue, 22 Jan 2008, Yinghai Lu wrote:

> On Monday 21 January 2008 01:37:09 pm Justin Piszcz wrote:
>>
>> On Mon, 21 Jan 2008, Yinghai Lu wrote:
>>
>>> On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
>>> please get x86.git
>>>
>>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>> cd linux-2.6
>>> #--------------{ x86.git instructions }---------->
>>> # Add Linus's tree as a remote
>>> git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>>
>>> # Add Ingo's tree as a remote
>>> git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>>>
>>> # With that setup, just run the following to get any changes you
>>> # don't have. It will also notice any new branches Ingo/Linus
>>> # add to their repo. Look in .git/config afterwards, the format
>>> # to add new remotes is easy to figure out.
>>> git remote update
>>> #-------------------------
>>> git merge x86/master
>>> git merge x86/mm
>>>
>>> and apply
>>>
>>> [PATCH] x86_64: check if Tom2 is enabled
>>> http://lkml.org/lkml/2008/1/21/20
>>> [PATCH] x86_64: update e820 instead of updating end_pfn v3
>>> http://lkml.org/lkml/2008/1/21/19
>>> [PATCH] x86_32: trim memory by updating e820 v2
>>> http://lkml.org/lkml/2008/1/21/18
>>>
>>> YH
>>>
>>
>> Thanks, I am all patched up and ready to test, unfortunately one of my disks
>> in my RAID 1 just died, I already filled out the advanced replacement form,
>> I will test when I receive the replacement disk.
>
> please get x86.git and apply
> [PATCH] x86_32: trim memory by updating e820 v3
> http://lkml.org/lkml/2008/1/22/394
>
> Ingo already put other two into the tree.
>
> Thanks
>
> YH
>

Tried it, it worked successfully!

With stock kernel, previous way I had to use it was mem=8832M and top
showed this:

top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers
Swap: 16787768k total, 0k used, 16787768k free, 178528k cached

With kernel you mentioned and use e820 v3:

top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
Swap: 16787768k total, 0k used, 16787768k free, 273928k cached

No append mem= required.

A full dmesg is attached so you can analyze the e820/MTRR mapping.

File: dmesg-e820v3patch.txt.bz2

Justin.


Attachments:
dmesg-e820v3patch.txt.bz2 (11.76 kB)

2008-01-26 00:16:35

by Yinghai Lu

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2

On Jan 25, 2008 4:01 PM, Justin Piszcz <[email protected]> wrote:
>
>
...
> Tried it, it worked successfully!
>
> With stock kernel, previous way I had to use it was mem=8832M and top
> showed this:
>
> top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
> Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie
> Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st
> Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers
> Swap: 16787768k total, 0k used, 16787768k free, 178528k cached
>
> With kernel you mentioned and use e820 v3:
>
> top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
> Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
> Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
> Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
> Swap: 16787768k total, 0k used, 16787768k free, 273928k cached
>
> No append mem= required.
>


thanks

any chance to try 32 bit with higemem64 option?

YH

2008-01-26 00:37:29

by Justin Piszcz

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2



On Fri, 25 Jan 2008, Yinghai Lu wrote:

> On Jan 25, 2008 4:01 PM, Justin Piszcz <[email protected]> wrote:
>>
>>
> ...
>> Tried it, it worked successfully!
>>
>> With stock kernel, previous way I had to use it was mem=8832M and top
>> showed this:
>>
>> top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
>> Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st
>> Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers
>> Swap: 16787768k total, 0k used, 16787768k free, 178528k cached
>>
>> With kernel you mentioned and use e820 v3:
>>
>> top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
>> Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
>> Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
>> Swap: 16787768k total, 0k used, 16787768k free, 273928k cached
>>
>> No append mem= required.
>>
>
>
> thanks
>
> any chance to try 32 bit with higemem64 option?
>
> YH
>

My distribution is setup for 64-bit (64bit-clean) only, I do not have a
32-bit userland, so cannot help here, sorry.

Justin.

2008-01-28 15:10:27

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2


* Justin Piszcz <[email protected]> wrote:

> Tried it, it worked successfully!
>
> With stock kernel, previous way I had to use it was mem=8832M and top
> showed this:
>
> top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
> Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie
> Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st
> Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers
> Swap: 16787768k total, 0k used, 16787768k free, 178528k cached
>
> With kernel you mentioned and use e820 v3:
>
> top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
> Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
> Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
> Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
> Swap: 16787768k total, 0k used, 16787768k free, 273928k cached
>
> No append mem= required.
>
> A full dmesg is attached so you can analyze the e820/MTRR mapping.

thanks for testing it! The code indeed successfully trimmed your memory
map by 64MB:

from:

[ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable)

to:

[ 0.000000] modified: 0000000100000000 - 0000000228000000 (usable)
[ 0.000000] modified: 0000000228000000 - 000000022c000000 (reserved)

what happened on your box previously when you booted without any
trimming - did it sometimes slow down or something like that?

Ingo

2008-01-28 18:07:44

by Justin Piszcz

[permalink] [raw]
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2



On Mon, 28 Jan 2008, Ingo Molnar wrote:

>
> * Justin Piszcz <[email protected]> wrote:
>
>> Tried it, it worked successfully!
>>
>> With stock kernel, previous way I had to use it was mem=8832M and top
>> showed this:
>>
>> top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
>> Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st
>> Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers
>> Swap: 16787768k total, 0k used, 16787768k free, 178528k cached
>>
>> With kernel you mentioned and use e820 v3:
>>
>> top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
>> Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
>> Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
>> Swap: 16787768k total, 0k used, 16787768k free, 273928k cached
>>
>> No append mem= required.
>>
>> A full dmesg is attached so you can analyze the e820/MTRR mapping.
>
> thanks for testing it! The code indeed successfully trimmed your memory
> map by 64MB:
>
> from:
>
> [ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable)
>
> to:
>
> [ 0.000000] modified: 0000000100000000 - 0000000228000000 (usable)
> [ 0.000000] modified: 0000000228000000 - 000000022c000000 (reserved)
>
> what happened on your box previously when you booted without any
> trimming - did it sometimes slow down or something like that?
>
> Ingo
>

When I boot the box without any trimming it acts like a 286 or 386, takes
about 10 minutes to boot (using raptor disks).

Justin.