Michal Hocko wrote:
> 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?
--
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>