[RFC][PATCH 0/5] consolidate i386 NUMA init code

[RFC][PATCH 0/5] consolidate i386 NUMA init code

[Dave Hansen]

The following five patches reorganize and consolidate some of the i386
NUMA/discontigmem code.  They grew out of some observations as we
produced the memory hotplug patches.

Only the first one is really necessary, as it makes the implementation
of one of the hotplug components much simpler and smaller.  2 and 3 came
from just looking at the effects on the code after 1.

4 and 5 aren't absolutely required for hotplug either, but do allow
sharing a bunch of code between the normal boot-time init and hotplug
cases.  

These are all on top of 2.6.11-rc2-mm1.

-- Dave

[RFC][PATCH 0/5] consolidate i386 NUMA init code

[Dave Hansen]

The following five patches reorganize and consolidate some of the i386
NUMA/discontigmem code.  They grew out of some observations as we
produced the memory hotplug patches.

Only the first one is really necessary, as it makes the implementation
of one of the hotplug components much simpler and smaller.  2 and 3 came
from just looking at the effects on the code after 1.

4 and 5 aren't absolutely required for hotplug either, but do allow
sharing a bunch of code between the normal boot-time init and hotplug
cases.  

These are all on top of 2.6.11-rc2-mm1.

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [RFC][PATCH 0/5] consolidate i386 NUMA init code

[Martin J. Bligh]

> The following five patches reorganize and consolidate some of the i386
> NUMA/discontigmem code.  They grew out of some observations as we
> produced the memory hotplug patches.
> 
> Only the first one is really necessary, as it makes the implementation
> of one of the hotplug components much simpler and smaller.  2 and 3 came
> from just looking at the effects on the code after 1.
> 
> 4 and 5 aren't absolutely required for hotplug either, but do allow
> sharing a bunch of code between the normal boot-time init and hotplug
> cases.  
> 
> These are all on top of 2.6.11-rc2-mm1.

Looks reasonable. How much testing have they had, on what platforms?

M

Re: [RFC][PATCH 0/5] consolidate i386 NUMA init code

[Martin J. Bligh]

> The following five patches reorganize and consolidate some of the i386
> NUMA/discontigmem code.  They grew out of some observations as we
> produced the memory hotplug patches.
> 
> Only the first one is really necessary, as it makes the implementation
> of one of the hotplug components much simpler and smaller.  2 and 3 came
> from just looking at the effects on the code after 1.
> 
> 4 and 5 aren't absolutely required for hotplug either, but do allow
> sharing a bunch of code between the normal boot-time init and hotplug
> cases.  
> 
> These are all on top of 2.6.11-rc2-mm1.

Looks reasonable. How much testing have they had, on what platforms?

M
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [RFC][PATCH 0/5] consolidate i386 NUMA init code

[Martin J. Bligh]

> Built on all the i386 configs here:
> http://sr71.net/patches/2.6.11/2.6.11-rc1-mm1-mhp1/configs/
> 
> Booted on x440 (summit and generic), numaq, 4-way PIII.  I would imagine
> that any problem would manifest as the system simply not booting.  The
> most likely to fail would be systems with DISCONTIG enabled, because
> that's where the greatest amount of churn happened.  The normal !
> DISCONTIG case still uses most of the same code.
> 
> Anyway, I think they're probably ready for a run in -mm, with the "if
> the machines don't boot check these first" flag set.  Although, I'd
> appreciate any other testing that anyone wants to throw at them.

Yup, as long as they boot, is probably good enough for now.

Thanks,

M.

Re: [RFC][PATCH 0/5] consolidate i386 NUMA init code

[Martin J. Bligh]

> Built on all the i386 configs here:
> http://sr71.net/patches/2.6.11/2.6.11-rc1-mm1-mhp1/configs/
> 
> Booted on x440 (summit and generic), numaq, 4-way PIII.  I would imagine
> that any problem would manifest as the system simply not booting.  The
> most likely to fail would be systems with DISCONTIG enabled, because
> that's where the greatest amount of churn happened.  The normal !
> DISCONTIG case still uses most of the same code.
> 
> Anyway, I think they're probably ready for a run in -mm, with the "if
> the machines don't boot check these first" flag set.  Although, I'd
> appreciate any other testing that anyone wants to throw at them.

Yup, as long as they boot, is probably good enough for now.

Thanks,

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [RFC][PATCH 0/5] consolidate i386 NUMA init code

[Dave Hansen]

On Wed, 2005-01-26 at 06:37 -0800, Martin J. Bligh wrote:
> > The following five patches reorganize and consolidate some of the i386
> > NUMA/discontigmem code.  They grew out of some observations as we
> > produced the memory hotplug patches.
> > 
> > Only the first one is really necessary, as it makes the implementation
> > of one of the hotplug components much simpler and smaller.  2 and 3 came
> > from just looking at the effects on the code after 1.
> > 
> > 4 and 5 aren't absolutely required for hotplug either, but do allow
> > sharing a bunch of code between the normal boot-time init and hotplug
> > cases.  
> > 
> > These are all on top of 2.6.11-rc2-mm1.
> 
> Looks reasonable. How much testing have they had, on what platforms?

Built on all the i386 configs here:
http://sr71.net/patches/2.6.11/2.6.11-rc1-mm1-mhp1/configs/

Booted on x440 (summit and generic), numaq, 4-way PIII.  I would imagine
that any problem would manifest as the system simply not booting.  The
most likely to fail would be systems with DISCONTIG enabled, because
that's where the greatest amount of churn happened.  The normal !
DISCONTIG case still uses most of the same code.

Anyway, I think they're probably ready for a run in -mm, with the "if
the machines don't boot check these first" flag set.  Although, I'd
appreciate any other testing that anyone wants to throw at them.

-- Dave

Re: [RFC][PATCH 0/5] consolidate i386 NUMA init code

[Dave Hansen]

On Wed, 2005-01-26 at 06:37 -0800, Martin J. Bligh wrote:
> > The following five patches reorganize and consolidate some of the i386
> > NUMA/discontigmem code.  They grew out of some observations as we
> > produced the memory hotplug patches.
> > 
> > Only the first one is really necessary, as it makes the implementation
> > of one of the hotplug components much simpler and smaller.  2 and 3 came
> > from just looking at the effects on the code after 1.
> > 
> > 4 and 5 aren't absolutely required for hotplug either, but do allow
> > sharing a bunch of code between the normal boot-time init and hotplug
> > cases.  
> > 
> > These are all on top of 2.6.11-rc2-mm1.
> 
> Looks reasonable. How much testing have they had, on what platforms?

Built on all the i386 configs here:
http://sr71.net/patches/2.6.11/2.6.11-rc1-mm1-mhp1/configs/

Booted on x440 (summit and generic), numaq, 4-way PIII.  I would imagine
that any problem would manifest as the system simply not booting.  The
most likely to fail would be systems with DISCONTIG enabled, because
that's where the greatest amount of churn happened.  The normal !
DISCONTIG case still uses most of the same code.

Anyway, I think they're probably ready for a run in -mm, with the "if
the machines don't boot check these first" flag set.  Although, I'd
appreciate any other testing that anyone wants to throw at them.

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>