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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
