der 4G which will
lead to boot failure.
This patch will first try to allocate memmap memory above 4G in sparse
vmemmap code.
If it failed, it will allocate memmap above MAX_DMA_ADDRESS.
This patch is against 2.6.24-rc1-git14
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
Signed-off-by: Sure
the code simple because strict_goal is
not supposed to be used in hot path.
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
diff -Nraup a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
--- a/arch/x86/mm/numa_64.c 2007-10-24 11:50:57.0
which will
lead to boot failure.
This patch will first try to allocate memmap memory above 4G in sparse
vmemmap code.
If it failed, it will allocate memmap above MAX_DMA_ADDRESS.
This patch is against 2.6.24-rc1-git14
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha
the code simple because strict_goal is
not supposed to be used in hot path.
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
diff -Nraup a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
--- a/arch/x86/mm/numa_64.c 2007-10-24 11:50:57.0 +0800
+++ b
to be used in hot path.
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
diff -Nraup a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
--- a/arch/x86/mm/numa_64.c 2007-10-24 11:50:57.0 +0800
+++ b/arch/x86/mm/numa_64.c 2007
rve bounce buffer under 4G which will
lead to boot failure.
This patch will first try to allocate memmap memory above 4G in sparse
vmemmap code.
If it failed, it will allocate memmap above MAX_DMA_ADDRESS.
This patch is against 2.6.24-rc1-git14
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
S
e(c->cpu_index) check in show_cpuinfo is invalid.
This patch will let cpuinfo_op use cpu_online_map instead of
cpu_present_map to iterate cpus.
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
--- linux-2.6.24-rc1/arch/x86/kernel/setup_64.c 2007-10-29 22:03:05.0
-0400
+++ b/arc
-cpu_index) check in show_cpuinfo is invalid.
This patch will let cpuinfo_op use cpu_online_map instead of
cpu_present_map to iterate cpus.
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
--- linux-2.6.24-rc1/arch/x86/kernel/setup_64.c 2007-10-29 22:03:05.0
-0400
+++ b/arch/x86/kernel/setup_64.c
to be used in hot path.
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
diff -Nraup a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
--- a/arch/x86/mm/numa_64.c 2007-10-24 11:50:57.0 +0800
+++ b/arch/x86/mm/numa_64.c 2007-11-07 13:06
bounce buffer under 4G which will
lead to boot failure.
This patch will first try to allocate memmap memory above 4G in sparse
vmemmap code.
If it failed, it will allocate memmap above MAX_DMA_ADDRESS.
This patch is against 2.6.24-rc1-git14
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
Signed-off
patch set cpu_index after identify_cpu to fix the issue.
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
--- linux-2.6.24-rc1/arch/x86/kernel/smpboot_64.c 2007-10-29
22:03:05.0 -0400
+++ b/arch/x86/kernel/smpboot_64.c 2007-11-05 22:12:57.0 -0500
@@ -141,8 +141
set cpu_index after identify_cpu to fix the issue.
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
--- linux-2.6.24-rc1/arch/x86/kernel/smpboot_64.c 2007-10-29
22:03:05.0 -0400
+++ b/arch/x86/kernel/smpboot_64.c 2007-11-05 22:12:57.0 -0500
@@ -141,8 +141,8 @@ static void
On Wed, 2007-10-31 at 14:04, Zou Nan hai wrote:
> On Tue, 2007-10-30 at 05:21, Martin Ebourne wrote:
> > On Mon, 2007-10-29 at 15:43 -0400, Dave Jones wrote:
> > > On Mon, Oct 29, 2007 at 08:03:09PM +0100, Andi Kleen wrote:
> > > > > > But if allocating bootm
p node 0 -1fff
> sparse_early_mem_map_alloc: returned address 8170b000
>
> My box has 512MB of RAM.
>
> Cheers,
>
> Martin.
Oops, sorry,
seem to be a mistake of me.
I forget to exclude the DMA range.
Does the following patch fix the i
to be a mistake of me.
I forget to exclude the DMA range.
Does the following patch fix the issue?
Thanks
Zou Nan hai
--- a/arch/x86/mm/init_64.c 2007-10-31 11:24:11.0 +0800
+++ b/arch/x86/mm/init_64.c 2007-10-31 12:31:02.0 +0800
@@ -731,7 +731,7 @@ int in_gate_area_no_task
On Wed, 2007-10-31 at 14:04, Zou Nan hai wrote:
On Tue, 2007-10-30 at 05:21, Martin Ebourne wrote:
On Mon, 2007-10-29 at 15:43 -0400, Dave Jones wrote:
On Mon, Oct 29, 2007 at 08:03:09PM +0100, Andi Kleen wrote:
But if allocating bootmem 4G doesn't work on these systems
most
cache_nice_tries and flags entry do not appear in proc fs sched_domain
directory,
because ctl_table entry is skipped.
This patch fix the issue.
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
--- linux-2.6.23-rc6/kernel/sched.c 2007-09-18 23:47:07.0 -0400
+++ b/kernel/s
cache_nice_tries and flags entry do not appear in proc fs sched_domain
directory,
because ctl_table entry is skipped.
This patch fix the issue.
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
--- linux-2.6.23-rc6/kernel/sched.c 2007-09-18 23:47:07.0 -0400
+++ b/kernel/sched.c2007
On Fri, 2007-05-18 at 03:32, Andrew Morton wrote:
> On 17 May 2007 10:40:07 +0800
> Zou Nan hai <[EMAIL PROTECTED]> wrote:
>
> >
> Please always prefer to use static inline functions rather than macros.
> They are more readable, they are more likely to have
On Fri, 2007-05-18 at 03:32, Andrew Morton wrote:
On 17 May 2007 10:40:07 +0800
Zou Nan hai [EMAIL PROTECTED] wrote:
Please always prefer to use static inline functions rather than macros.
They are more readable, they are more likely to have comments attached to
them and they provide
to sparsemem model.
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
Acked-by: Siddha, Suresh <[EMAIL PROTECTED]>
---
include/asm-x86_64/mmzone.h |5 +
include/linux/bootmem.h |3 +++
mm/sparse.c |5 +
3 files changed, 13 insertions(+)
diff -Nraup a/includ
to sparsemem model.
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
Acked-by: Siddha, Suresh [EMAIL PROTECTED]
---
include/asm-x86_64/mmzone.h |5 +
include/linux/bootmem.h |3 +++
mm/sparse.c |5 +
3 files changed, 13 insertions(+)
diff -Nraup a/include/asm-x86_64
There is an obvious error in the header of /proc/slabinfo
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
--- linux-2.6.11-rc3/mm/slab.c 2005-02-03 13:29:33.0 +0800
+++ linux-2.6.11-rc3-fix/mm/slab.c 2005-02-03 13:32:42.318821400 +0800
@@ -2860,7 +2860,7 @@ static void *s
There is an obvious error in the header of /proc/slabinfo
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
--- linux-2.6.11-rc3/mm/slab.c 2005-02-03 13:29:33.0 +0800
+++ linux-2.6.11-rc3-fix/mm/slab.c 2005-02-03 13:32:42.318821400 +0800
@@ -2860,7 +2860,7 @@ static void *s_start(struct
spend in lat_proc fork is copy_page_range
in fork path and clear_page_range in the exit path. Now they are 1 level
deeper.
Though pud and pgd is same on IA64, there is still some overhead
introduced I think.
Are any other architectures seeing the same sort of results?
Zou Nan hai
spend in lat_proc fork is copy_page_range
in fork path and clear_page_range in the exit path. Now they are 1 level
deeper.
Though pud and pgd is same on IA64, there is still some overhead
introduced I think.
Are any other architectures seeing the same sort of results?
Zou Nan hai
(*src_pgd) or pgd_bad(*src_pgd).
Although maybe this bug does not break anything currently...,
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
--- a/mm/memory.c 2005-01-21 01:21:18.0 +0800
+++ b/mm/memory.c 2005-01-21 04:49:13.0 +0800
@@ -442,17 +442,18
(*src_pgd) or pgd_bad(*src_pgd).
Although maybe this bug does not break anything currently...,
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
--- a/mm/memory.c 2005-01-21 01:21:18.0 +0800
+++ b/mm/memory.c 2005-01-21 04:49:13.0 +0800
@@ -442,17 +442,18 @@ int copy_page_range
28 matches
Mail list logo
