lkml.org 
[lkml]   [2011]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch for-3.2-rc3] cpusets: stall when updating mems_allowed for mempolicy or disjoint nodemask
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.


\
 
 \ /
  Last update: 2011-11-23 07:27    [W:0.068 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site