Re: [PATCH] GFP_THISNODE for the slab allocator

[David Rientjes <rientjes@google.com>]

On Mon, 18 Sep 2006, Paul Jackson wrote:

> For now, it could be that we can't handle hybrid systems, and that fake
> numa systems simply have a distance table of all 10's, driven by the
> kernel boot command "numa=fake=N".  But that apparatus will have to be
> extended at some point, to support hybrid fake and real NUMA combined.
> And this will have to mature from being an arch=x86_64 only thing to
> being generically available.  And it will have to become a mechanism
> that can be applied on a running system, creating (and removing) fake
> nodes on the fly, without a reboot, so long as the required physical
> memory is free and available.
> 

Magnus Damm wrote a series of patches that divided real NUMA nodes into 
several smaller emulated nodes (real nodes - 1) for the x86_64.  They are 
from 2.6.14-mm1:

http://marc.theaimsgroup.com/?l=linux-mm&m=113161386520342&w=2

As already said, the only flag that exists to determine whether 
CONFIG_NUMA_EMU is enabled and numa=fake is being used (and used 
correctly) is the numa_fake int in arch/x86_64/mm/numa.c.  Any abstraction 
of this to generic kernel code should probably follow in the footsteps of 
Magnus' other patch series which moved must of NUMA emulation to generic 
architectures.  He used it primarily for implementing numa=fake on i386:

http://marc.theaimsgroup.com/?l=linux-mm&m=112806587501884&w=2

At the time it was suggested to emulate an SMP NUMA system where each 
node doesn't have all of its CPU's online.

		David

--
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:"dont@kvack.org"> email@kvack.org </a>