Re: [PATCH 6/5] oom, oom_reaper: disable oom_reaper for oom_kill_allocating_task

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue 15-03-16 20:15:24, Tetsuo Handa wrote:
[...]
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 23b8b06..0464727 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -543,7 +543,7 @@ static int oom_reaper(void *unused)
>  
>  static void wake_oom_reaper(struct task_struct *tsk)
>  {
> -	if (!oom_reaper_th)
> +	if (!oom_reaper_th || tsk->oom_reaper_list)
>  		return;
>  
>  	get_task_struct(tsk);

OK, this is indeed much simpler. Back then when the list_head was used
this would be harder and I didn't realize moving away from the list_head
would simplify this as well. Care to send a patch to replace the
oom-oom_reaper-disable-oom_reaper-for-oom_kill_allocating_task.patch in
the mmotm tree?

> Two thread groups sharing the same mm can disable the OOM reaper
> when all threads in the former thread group (which will be chosen
> as an OOM victim by the OOM killer) can immediately call exit_mm()
> via do_exit() (e.g. simply sleeping in killable state when the OOM
> killer chooses that thread group) and some thread in the latter thread
> group is contended on unkillable locks (e.g. inode mutex), due to
> 
> 	p = find_lock_task_mm(tsk);
> 	if (!p)
> 		return true;
> 
> in __oom_reap_task() and
> 
> 	can_oom_reap = !test_and_set_bit(MMF_OOM_KILLED, &mm->flags);
> 
> in oom_kill_process(). The OOM reaper is woken up in order to reap
> the former thread group's memory, but it does nothing on the latter
> thread group's memory because the former thread group can clear its mm
> before the OOM reaper locks its mm. Even if subsequent out_of_memory()
> call chose the latter thread group, the OOM reaper will not be woken up.
> No memory is reaped. We need to queue all thread groups sharing that
> memory if that memory should be reaped.

Why it wouldn't be enough to wake the oom reaper only for the oom
victims? If the oom reaper races with the victims exit path then
the next round of the out_of_memory will select a different thread
sharing the same mm.

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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]