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
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
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
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
(*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
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
-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
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 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
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
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
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
(*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
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo