Re: [patch for-3.2-rc3] cpusets: stall when updating mems_allowedfor mempolicy or disjoint nodemask

[David Rientjes]

On Wed, 23 Nov 2011, Miao Xie wrote:

> This is a good idea. But I worry that oom will happen easily, because we do
> direct reclamation and compact by mems_allowed.
> 

Memory compaction actually iterates through each zone regardless of 
whether it's allowed or not in the current context.  Recall that the 
nodemask passed into __alloc_pages_nodemask() is non-NULL only when there 
is a mempolicy that restricts the allocations by MPOL_BIND.  That nodemask 
is not protected by get_mems_allowed(), so there's no change in 
compaction's behavior with my patch.

Direct reclaim does, however, require mems_allowed staying constant 
without the risk of early oom as you mentioned.  It has its own 
get_mems_allowed(), though, so it doesn't have the opportunity to change 
until returning to the page allocator.  It's possible that mems_allowed 
will be different on the next call to get_pages_from_freelist() but we 
don't know anything about that context: it's entirely possible that the 
set of new mems has an abundance of free memory or are completely depleted 
as well.  So there's no strict need for consistency between the set of 
allowed nodes during reclaim and the subsequent allocation attempt.  All 
we care about is that reclaim has a consistent set of allowed nodes to 
determine whether it's making progress or not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/