Re: Is GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM supported?

[Michal Hocko <mhocko@kernel.org>]

On Tue 02-01-18 18:56:56, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 02-01-18 11:08:47, Tetsuo Handa wrote:
> > > virtio-balloon wants to try allocation only when that allocation does not cause
> > > OOM situation. Since there is no gfp flag which succeeds allocations only if
> > > there is plenty of free memory (i.e. higher watermark than other requests),
> > > virtio-balloon needs to watch for OOM notifier and release just allocated memory
> > > when OOM notifier is invoked.
> > 
> > I do not understand the last part mentioning OOM notifier.
> > 
> > > Currently virtio-balloon is using
> > > 
> > >   GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY
> > > 
> > > for allocation, but is
> > > 
> > >   GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM
> > > 
> > > supported (from MM subsystem's point of view) ?
> > 
> > Semantically I do not see any reason why we shouldn't support
> > non-sleeping user allocation with an explicit nomemalloc flag.
> 
> I see. Then, allocating with balloon_lock held can become a choice.
> 
> The virtio-balloon driver is trying to allocate many pages using
> GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY for inflating the
> balloon, and then hold the balloon_lock, and then is trying to allocate some
> more pages using GFP_NOWAIT for faster communication using scatter-gather API.
> 
> Unfortunately, since the former memory is not visible to OOM notifier path until
> the latter memory is allocated, when someone hit OOM notifier path before the
> driver holds the balloon_lock, the driver fails to release the former memory
> (i.e. premature OOM killer invocation).
> 
> While it would be possible to make the former memory visible to OOM notifier path,
> allocating (GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM and
> GFP_NOWAIT with the balloon_lock held would simplify the code.
> 
> >                                                                Btw. why
> > is __GFP_NOMEMALLOC needed at all?
> 
> Because there is no need to use memory reserves for memory allocations for
> inflating the balloon. If we use memory reserves for inflating the balloon,
> some allocation request will immediately hit OOM notifier path, and we will
> after all release memory allocated from memory reserves.

Well, the primary reason to use __GFP_NOMEMALLOC is to override either
PF_MEMALLOC or an explicit use of __GFP_MEMALLOC from the above layer.
Normally you shouldn't really care. So the question is whether this
allocation is called from a context which uses the above...

> Although there will be no need to specify __GFP_NOMEMALLOC because it is
> a workqueue context

... so the above doesn't seem to be the case.

> which does this allocation (which will never cause
> __gfp_pfmemalloc_flags() to return ALLOC_OOM), I think there will be
> no harm with shortcutting __gfp_pfmemalloc_flags() by specifying
> __GFP_NOMEMALLOC.

I do not see a reason why. Moreover I think the usage of
__GFP_NOMEMALLOC should be reduced because it tends to be wrong in many
cases. People just tend to add it without a deeper understanding why.

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>