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 Tue, 22 Nov 2011 22:25:46 -0800 (pst), David Rientjes wrote:
> 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.

That nodemask is also protected by get_mems_allowed().

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

Agree.


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