Re: [PATCH 3/6] hugetlb: introduce alloc_nodemask_of_node

[David Rientjes <rientjes@google.com>]

On Thu, 10 Sep 2009, Andrew Morton wrote:

> > > alloc_nodemask_of_node() has no callers, so I can think of a good fix
> > > for these problems.  If it _did_ have a caller then I might ask "can't
> > > we fix this by moving alloc_nodemask_of_node() into the .c file".  But
> > > it doesn't so I can't.
> > > 
> > 
> > It gets a caller in patch 5 of the series in set_max_huge_pages().
> 
> ooh, there it is.
> 
> So alloc_nodemask_of_node() could be moved into mm/hugetlb.c.
> 

We discussed that, but the consensus was that it specific to mempolicies 
not hugepages.  Perhaps someday it will gain another caller.

> > My early criticism of both alloc_nodemask_of_node() and 
> > alloc_nodemask_of_mempolicy() was that for small CONFIG_NODES_SHIFT (say, 
> > 6 or less, which covers all defconfigs except ia64), it is perfectly 
> > reasonable to allocate 64 bytes on the stack in the caller.
> 
> Spose so.  But this stuff is only called when userspace reconfigures
> via sysfs, so it'll be low bandwidth (one sincerely hopes).
> 

True, but order-0 GFP_KERNEL allocations will loop forever in the page 
allocator and kill off tasks if it can't allocate memory.  That wouldn't 
necessarily be a cause for concern other than the fact that this tunable 
is already frequently written when memory is low to reclaim pages.

 [ If we're really tailoring it only for its current use case, though, the 
   stack could easily support even NODES_SHIFT of 10. ]

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