lkml.org 
[lkml]   [2013]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] mm, page_alloc: allow __GFP_NOFAIL to allocate below watermarks after reclaim
On Tue, 10 Dec 2013, Mel Gorman wrote:

> > If direct reclaim has failed to free memory, __GFP_NOFAIL allocations
> > can potentially loop forever in the page allocator. In this case, it's
> > better to give them the ability to access below watermarks so that they
> > may allocate similar to the same privilege given to GFP_ATOMIC
> > allocations.
> >
> > We're careful to ensure this is only done after direct reclaim has had
> > the chance to free memory, however.
> >
> > Signed-off-by: David Rientjes <rientjes@google.com>
>
> The main problem with doing something like this is that it just smacks
> into the adjusted watermark if there are a number of __GFP_NOFAIL. Who
> was the user of __GFP_NOFAIL that was fixed by this patch?
>

Nobody, it comes out of a memcg discussion where __GFP_NOFAIL were
recently given the ability to bypass charges to the root memcg when the
memcg has hit its limit since we disallow the oom killer to kill a process
(for the same reason that the vast majority of __GFP_NOFAIL users, those
that do GFP_NOFS | __GFP_NOFAIL, disallow the oom killer in the page
allocator).

Without some other thread freeing memory, these allocations simply loop
forever. We probably don't want to reconsider the choice that prevents
calling the oom killer in !__GFP_FS contexts since it will allow
unnecessary oom killing when memory can actually be freed by another
thread.

Since there are comments in both gfp.h and page_alloc.c that say no new
users will be added, it seems legitimate to ensure that the allocation
will at least have a chance of succeeding, but not the point of depleting
memory reserves entirely.

> There are enough bad users of __GFP_NOFAIL that I really question how
> good an idea it is to allow emergency reserves to be used when they are
> potentially leaked to other !__GFP_NOFAIL users via the slab allocator
> shortly afterwards.
>

You could make the same argument for GFP_ATOMIC which can also allow
access to memory reserves.


\
 
 \ /
  Last update: 2013-12-11 00:41    [W:0.098 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site