On Wed 01-06-16 00:03:53, Tetsuo Handa wrote:

Michal Hocko wrote:

quoted

task_will_free_mem is rather weak. It doesn't really tell whether
the task has chance to drop its mm. 98748bd72200 ("oom: consider
multi-threaded tasks in task_will_free_mem") made a first step
into making it more robust for multi-threaded applications so now we
know that the whole process is going down and probably drop the mm.

This patch builds on top for more complex scenarios where mm is shared
between different processes - CLONE_VM without CLONE_THREAD resp
CLONE_SIGHAND, or in kernel use_mm().

Make sure that all processes sharing the mm are killed or exiting. This
will allow us to replace try_oom_reaper by wake_oom_reaper. Therefore
all paths which bypass the oom killer are now reapable and so they
shouldn't lock up the oom killer.

Really? The can_oom_reap variable was not removed before this patch.
It means that oom_kill_process() might fail to call wake_oom_reaper()
while setting TIF_MEMDIE to one of threads using that mm_struct.
If use_mm() or global init keeps that mm_struct not OOM reapable, other
threads sharing that mm_struct will get task_will_free_mem() == false,
won't it?

How is it guaranteed that task_will_free_mem() == false && oom_victims > 0
shall not lock up the OOM killer?

But this patch is talking about task_will_free_mem == true. Is the
description confusing? Should I reword the changelog?
-- 
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>