Thread (64 messages) 64 messages, 4 authors, 2016-03-17

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

From: Michal Hocko <mhocko@kernel.org>
Date: 2016-03-15 11:43:03

On Tue 15-03-16 20:15:24, Tetsuo Handa wrote:
[...]
quoted hunk ↗ jump to hunk
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@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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help