Re: [RFC 3/8] mm: page_alloc: do not lock up GFP_NOFS allocations upon OOM

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

Michal Hocko wrote:
> > Therefore, I worry that, under nearly OOM condition where waiting for kswapd
> > kernel threads for a few seconds will reclaim FS memory which will be enough
> > to succeed the !__GFP_FS allocations, GFP_NOFS allocations start failing
> > prematurely. The toehold (reliability by __GFP_WAIT) is almost gone.
> 
> GFP_NOFS had to go through the full reclaim process to end up in the oom
> path. All that without making _any_ progress. kswapd should be running
> in the background so talking about waiting for few seconds doesn't solve
> much once we have hit the oom path. You can be lucky under some very
> specific conditions but in general we _are_ OOM.

As a GFP_NOFS user from syscalls than filesystem's writebacks (some of LSM
hooks are called with fs locks held), I'm happy to give up upon SIGKILL but
I'm not happy to return -ENOMEM without retrying hard. Returning -ENOMEM to
user space is nearly equals to terminating that process because what user
space programs likely do upon unexpected -ENOMEM is to call exit(). Therefore,
I prefer OOM killing some memory hog process than potentially terminating
important processes which can be controlled via /proc/pid/oom_score_adj .

As a troubleshooting staff, I wish that we have a mechanism for proving that
the cause of silent hang up (hangups without the OOM killer messages) are not
caused by mm subsystem's behavior. How can we prove if memory allocation
requests stuck before reaching the oom path (e.g. inside shrinker functions
or shrink_inactive_list())? I want to use something like khungtaskd.

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