On Wed 01-06-16 00:03:53, Tetsuo Handa wrote:
> 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?
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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>