Re: [PATCH] populated_map: fix !NUMA case, remove comment

[Lee Schermerhorn <Lee.Schermerhorn@hp.com>]

On Thu, 2007-06-14 at 09:15 -0700, Christoph Lameter wrote:
> On Thu, 14 Jun 2007, Nishanth Aravamudan wrote:
> 
> > > The point of all this is that, as you've pointed out, the original
> > > NUMA and memory policy designs assumed a fairly symmetric system
> > > configuration with all nodes populated with [similar amounts?] of
> > > roughly equivalent memory.  That probably describes a majority of NUMA
> > > systems, so the system should handle this well, as a default.  We
> > > still need to be able to handle the less symmetric configs--with boot
> > > parameters, sysctls, cpusets, ...--that specify non-default behavior,
> > > and cause the generic code to do the right thing.  Certainly, the
> > > generic code can't "fall over and die" in the presence of memoryless
> > > nodes or other "interesting" configurations.
> > 
> > Agreed,
> > Nish
> 
> The generic code currently does not fail. It (slab allocators etc) simply 
> gets memory that it thinks comes from a memoryless node but it came from a 
> neighboring node.
> 

If it (slab allocators etc) wants and/or can use memory from a different
node from what it requested, then, it shouldn't be calling with
GFP_THISNODE, right?  I mean what's the point?  If GFP_THISNODE never
returned off-node memory, then one couldn't use it without checking for
and dealing with failure.  And, 'THISNODE allocations CAN fail, when the
first zone in the selected zonelist is empty and subsequent zones are
off-node.  __alloc_pages() et al WILL fail this case and return NULL, so
callers must be prepared to deal with it--even [especially?] early boot
code, IMO, anyway.

Again, I'll try your latest stack with Nish's patches and see what
happens.

Lee




--
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>