[lkml]   [2009]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: upcoming item: get_page_from_freelist
On Mon, 29 Jun 2009, Mel Gorman wrote:

> page-allocator: Ensure that processes that have been OOM killed exit the page allocator
> Processes that have been OOM killed set the thread flag TIF_MEMDIE. A
> process such as this is expected to exit the page allocator but in the
> event it happens to have set __GFP_NOFAIL, it potentially loops forever.

That's not the expected behavior for TIF_MEMDIE, although your patch
certainly changes that.

Your patch is simply doing

if (test_thread_flag(TIF_MEMDIE))
gfp_mask |= __GFP_NORETRY;

in the slowpath.

TIF_MEMDIE is supposed to allow allocations to succeed, not automatically
fail, so that it can quickly handle its SIGKILL without getting blocked in
the exit path seeking more memory.

> This patch checks TIF_MEMDIE when deciding whether to loop again in the
> page allocator. Such a process will now return NULL after direct reclaim
> and OOM killing have both been considered as options. The potential
> problem is that a __GFP_NOFAIL allocation can still return failure so
> callers must still handle getting returned NULL.

All __GFP_NOFAIL allocations should ensure that alloc_pages() never
returns NULL. Although it's unfortunate, that's the requirement that
callers have been guaranteed and until they are fixed, the page allocator
should respect it.

I disagree with this change because it unconditionally fails allocations
when a task has been oom killed, a scenario which should be the _highest_
priority for allocations to succeed since it leads to future memory

Additionally, this will fail all GFP_ATOMIC allocations for oom killed
tasks if allocating without watermarks fails although pdflush may
concurrently be doing writeback or other allocation attempts are invoking
direct reclaim.

 \ /
  Last update: 2009-06-30 01:37    [W:0.131 / U:4.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site