Re: [PATCH v2] mm,oom: Re-enable OOM killer using timeout.

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

Michal Hocko wrote:
> Hmm, I guess we have already discussed that in the past but I might
> misremember. The above relies on oom killer to be triggered after the
> previous victim was selected. There is no guarantee this will happen.

Why there is no guarantee this will happen?

This OOM livelock is caused by waiting for TIF_MEMDIE threads forever
unconditionally. If oom_unkillable_task() is not called, it is not
the OOM killer's problem.

Are you talking about doing did_some_progress = 1 for !__GFP_FS && !__GFP_NOFAIL
allocations without calling oom_unkillable_task() ? Then, I insist that this is
the page allocator's problem. GFP_NOIO and GFP_NOFS allocations wake up kswapd,
and kswapd does __GFP_FS reclaim. If the kswapd is unable to make forward
progress (an example is
http://I-love.SAKURA.ne.jp/tmp/serial-20160314-too-many-isolated2.txt.xz

----------
[  485.216878] Out of memory: Kill process 1356 (a.out) score 999 or sacrifice child
[  485.219170] Killed process 1356 (a.out) total-vm:4176kB, anon-rss:80kB, file-rss:0kB, shmem-rss:0kB
[  514.255929] MemAlloc-Info: stalling=146 dying=0 exiting=0 victim=0 oom_count=1/226
(...snipped...)
[  540.998623] MemAlloc-Info: stalling=146 dying=0 exiting=0 victim=0 oom_count=1/226
[  571.003817] MemAlloc-Info: stalling=152 dying=0 exiting=0 victim=0 oom_count=1/226
(...snipped...)
[  585.888300] MemAlloc-Info: stalling=152 dying=0 exiting=0 victim=0 oom_count=1/226
----------
), we are already OOM and we need to hear from administrator's decision (i.e.
either fail !__GFP_FS && !__GFP_NOFAIL allocations or select an OOM victim).
This OOM livelock is caused by waiting for somebody else forever unconditionally.

These OOM livelocks are caused by lack of mechanism for hearing administrator's
policy. We are missing rescue mechanisms which are needed for recovering from
situations your model did not expect.

I'm talking about corner cases where your deterministic approach fail. What we
need is "stop waiting for something forever unconditionally" and "hear what the
administrator wants to do". You can deprecate and then remove sysctl knobs for
hearing what the administrator wants to do when you developed perfect model and
mechanism.

> Why cannot we get back to the timer based solution at least for the
> panic timeout?

Use of global timer can cause false positive panic() calls.
Timeout should be calculated for per task_struct or signal_struct basis.

Also, although a different problem, global timer based solution does not
work for OOM livelock without any TIF_MEMDIE thread case (an example
shown above).

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