[lkml]   [2013]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] mm: memcg: do not declare OOM from __GFP_NOFAIL allocations
On Thu, 28 Nov 2013, Michal Hocko wrote:

> > Ok, so let's forget about GFP_KERNEL | __GFP_NOFAIL since anything doing
> > __GFP_FS should not be holding such locks, we have some of those in the
> > drivers code and that makes sense that they are doing GFP_KERNEL.
> >
> > Focusing on the GFP_NOFS | __GFP_NOFAIL allocations in the filesystem
> > code, the kernel oom killer independent of memcg never gets called because
> > !__GFP_FS and they'll simply loop around the page allocator forever.
> >
> > In the past, Andrew has expressed the desire to get rid of __GFP_NOFAIL
> > entirely since it's flawed when combined with GFP_NOFS (and GFP_KERNEL |
> > __GFP_NOFAIL could simply be reimplemented in the caller) because of the
> > reason you point out in addition to making it very difficult in the page
> > allocator to free memory independent of memcg.
> >
> > So I'm wondering if we should just disable the oom killer in memcg for
> > __GFP_NOFAIL as you've done here, but not bypass to the root memcg and
> > just allow them to spin? I think we should be focused on the fixing the
> > callers rather than breaking memcg isolation.
> What if the callers simply cannot deal with the allocation failure?
> 84235de394d97 (fs: buffer: move allocation failure loop into the
> allocator) describes one such case when __getblk_slow tries desperately
> to grow buffers relying on the reclaim to free something. As there might
> be no reclaim going on we are screwed.

My suggestion is to spin, not return NULL. Bypassing to the root memcg
can lead to a system oom condition whereas if memcg weren't involved at
all the page allocator would just spin (because of !__GFP_FS).

> That being said, while I do agree with you that we should strive for
> isolation as much as possible there are certain cases when this is
> impossible to achieve without seeing much worse consequences. For now,
> we hope that __GFP_NOFAIL is used very scarcely.

If that's true, why not bypass the per-zone min watermarks in the page
allocator as well to allow these allocations to succeed?

 \ /
  Last update: 2013-11-30 01:01    [W:0.051 / U:1.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site