[PATCH] PPC64 NUMA memory fixup (another try)

2005-03-16 Thread Mike Kravetz
Below is a new version of the patch that allows holes within nodes on ppc64 NUMA. I would appreciate it if someone familiar with OF device tree parsing could take a look at this part of the code. So far, I've gotten this wrong twice. Patch was tested in various configurations on a G5 and

[PATCH] PPC64 NUMA memory fixup (another try)

2005-03-16 Thread Mike Kravetz
Below is a new version of the patch that allows holes within nodes on ppc64 NUMA. I would appreciate it if someone familiar with OF device tree parsing could take a look at this part of the code. So far, I've gotten this wrong twice. Patch was tested in various configurations on a G5 and

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread Andrew Morton
mike kravetz <[EMAIL PROTECTED]> wrote: > > Here is another version of the patch. This one gets the cell sizes > before extracting the cells. I have made this change to existing > code in the file, as well as the code I added. This works fine on > my 720, but so did the previous patch. :)

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread mike kravetz
Here is another version of the patch. This one gets the cell sizes before extracting the cells. I have made this change to existing code in the file, as well as the code I added. This works fine on my 720, but so did the previous patch. :) I'd appreciate it if someone could touch test this on

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread mike kravetz
On Fri, Mar 11, 2005 at 07:51:38PM +1100, Paul Mackerras wrote: > > Anyway, the ultimate reason seems to be that the numa.c code is > assuming that an address value and a size value occupy the same number > of cells. On the G5 we have #address-cells = 2 but #size-cells = 1. > Previously this

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread Paul Mackerras
Andrew Morton writes: > This patch causes the non-numa G5 to oops very early in boot in > smp_call_function(). Hmmm, the reason we are getting into smp_call_function is that we have panicked due to not being able to allocate boot memory. It's kind of sad that we can't even panic successfully,

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread Paul Mackerras
Andrew Morton writes: This patch causes the non-numa G5 to oops very early in boot in smp_call_function(). Hmmm, the reason we are getting into smp_call_function is that we have panicked due to not being able to allocate boot memory. It's kind of sad that we can't even panic successfully,

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread mike kravetz
On Fri, Mar 11, 2005 at 07:51:38PM +1100, Paul Mackerras wrote: Anyway, the ultimate reason seems to be that the numa.c code is assuming that an address value and a size value occupy the same number of cells. On the G5 we have #address-cells = 2 but #size-cells = 1. Previously this didn't

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread mike kravetz
Here is another version of the patch. This one gets the cell sizes before extracting the cells. I have made this change to existing code in the file, as well as the code I added. This works fine on my 720, but so did the previous patch. :) I'd appreciate it if someone could touch test this on

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-11 Thread Andrew Morton
mike kravetz [EMAIL PROTECTED] wrote: Here is another version of the patch. This one gets the cell sizes before extracting the cells. I have made this change to existing code in the file, as well as the code I added. This works fine on my 720, but so did the previous patch. :) I'd

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-10 Thread mike kravetz
On Thu, Mar 10, 2005 at 02:36:13AM -0800, Andrew Morton wrote: > > This patch causes the non-numa G5 to oops very early in boot in > smp_call_function(). > OK - Let me take a look. -- Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-10 Thread Andrew Morton
Paul Mackerras <[EMAIL PROTECTED]> wrote: > > When I booted my new 720 on a kernel configured for NUMA, I received > the following during bootup: > > WARNING: Unexpected node layout: region start 4400 length 200 > NUMA is disabled > > This is due to memory 'holes' within nodes. If

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-10 Thread Andrew Morton
Paul Mackerras [EMAIL PROTECTED] wrote: When I booted my new 720 on a kernel configured for NUMA, I received the following during bootup: WARNING: Unexpected node layout: region start 4400 length 200 NUMA is disabled This is due to memory 'holes' within nodes. If such holes

Re: [PATCH] PPC64 NUMA memory fixup

2005-03-10 Thread mike kravetz
On Thu, Mar 10, 2005 at 02:36:13AM -0800, Andrew Morton wrote: This patch causes the non-numa G5 to oops very early in boot in smp_call_function(). OK - Let me take a look. -- Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL

[PATCH] PPC64 NUMA memory fixup

2005-03-08 Thread Paul Mackerras
This patch is from Mike Kravetz <[EMAIL PROTECTED]>. When I booted my new 720 on a kernel configured for NUMA, I received the following during bootup: WARNING: Unexpected node layout: region start 4400 length 200 NUMA is disabled This is due to memory 'holes' within nodes. If such

[PATCH] PPC64 NUMA memory fixup

2005-03-08 Thread Paul Mackerras
This patch is from Mike Kravetz [EMAIL PROTECTED]. When I booted my new 720 on a kernel configured for NUMA, I received the following during bootup: WARNING: Unexpected node layout: region start 4400 length 200 NUMA is disabled This is due to memory 'holes' within nodes. If such holes