Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully
From: Michal Hocko <mhocko@kernel.org>
Date: 2016-06-08 07:27:47
Also in:
lkml
On Wed 08-06-16 06:49:24, Tetsuo Handa wrote:
Michal Hocko wrote:quoted
OK, so you are arming the timer for each mark_oom_victim regardless of the oom context. This means that you have replaced one potential lockup by other potential livelocks. Tasks from different oom domains might interfere here... Also this code doesn't even seem easier. It is surely less lines of code but it is really hard to realize how would the timer behave for different oom contexts.If you worry about interference, we can use per signal_struct timestamp. I used per task_struct timestamp in my earlier versions (where per task_struct TIF_MEMDIE check was used instead of per signal_struct oom_victims).
This would allow pre-mature new victim selection for very large victims (note that exit_mmap can take a while depending on the mm size). It also pushed the timeout heuristic for everybody which will sooner or later open a question why is this $NUMBER rathen than $NUMBER+$FOO. [...]
But expiring timeout by sleeping inside oom_kill_process() prevents other threads which are OOM-killed from obtaining TIF_MEMDIE, for anybody needs to wait for oom_lock in order to obtain TIF_MEMDIE.
True, but please note that this will happen only for the _unlikely_ case when the mm is shared with kthread or init. All other cases would rely on the oom_reaper which has a feedback mechanism to tell the oom killer to move on if something bad is going on.
Unless you set TIF_MEMDIE to all OOM-killed threads from oom_kill_process() or allow the caller context to use ALLOC_NO_WATERMARKS by checking whether current was already OOM-killed rather than TIF_MEMDIE, attempt to expiring timeout by sleeping inside oom_kill_process() is useless.
Well this is a rather strong statement for a highly unlikely corner case, don't you think? I do not mind fortifying this class of cases some more if we ever find out they are a real problem but I would rather make sure they cannot lockup at this stage rather than optimize for them. To be honest I would rather explore ways to handle kthread case (which is the only real one IMHO from the two) gracefully and made them a nonissue - e.g. enforce EFAULT on a dead mm during the kthread page fault or something similar. -- 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>