* Is GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM supported?
@ 2018-01-02 2:08 Tetsuo Handa
2018-01-02 9:14 ` Michal Hocko
0 siblings, 1 reply; 4+ messages in thread
From: Tetsuo Handa @ 2018-01-02 2:08 UTC (permalink / raw)
To: mhocko; +Cc: linux-mm, wei.w.wang, willy, mst
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.
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) ?
--
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM supported?
2018-01-02 2:08 Is GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM supported? Tetsuo Handa
@ 2018-01-02 9:14 ` Michal Hocko
2018-01-02 9:56 ` Tetsuo Handa
0 siblings, 1 reply; 4+ messages in thread
From: Michal Hocko @ 2018-01-02 9:14 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-mm, wei.w.wang, willy, mst
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. Btw. why
is __GFP_NOMEMALLOC needed at all?
--
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM supported?
2018-01-02 9:14 ` Michal Hocko
@ 2018-01-02 9:56 ` Tetsuo Handa
2018-01-02 11:40 ` Michal Hocko
0 siblings, 1 reply; 4+ messages in thread
From: Tetsuo Handa @ 2018-01-02 9:56 UTC (permalink / raw)
To: mhocko; +Cc: linux-mm, wei.w.wang, willy, mst
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM supported?
2018-01-02 9:56 ` Tetsuo Handa
@ 2018-01-02 11:40 ` Michal Hocko
0 siblings, 0 replies; 4+ messages in thread
From: Michal Hocko @ 2018-01-02 11:40 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-mm, wei.w.wang, willy, mst
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-01-02 11:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-02 2:08 Is GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC) & ~__GFP_DIRECT_RECLAIM supported? Tetsuo Handa
2018-01-02 9:14 ` Michal Hocko
2018-01-02 9:56 ` Tetsuo Handa
2018-01-02 11:40 ` Michal Hocko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.