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

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

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.

Although there will be no need to specify __GFP_NOMEMALLOC because it is
a workqueue context 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.

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