Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing
From: Michal Hocko <mhocko@kernel.org>
Date: 2016-02-06 08:38:03
Also in:
lkml
On Sat 06-02-16 14:54:24, Tetsuo Handa wrote:
Michal Hocko wrote:quoted
quoted
But if we consider non system-wide OOM events, it is not very unlikely to hit this race. This queue is useful for situations where memcg1 and memcg2 hit memcg OOM at the same time and victim1 in memcg1 cannot terminate immediately.This can happen of course but the likelihood is _much_ smaller without the global OOM because the memcg OOM killer is invoked from a lockless context so the oom context cannot block the victim to proceed.Suppose mem_cgroup_out_of_memory() is called from a lockless context via mem_cgroup_oom_synchronize() called from pagefault_out_of_memory(), that "lockless" is talking about only current thread, doesn't it?
Yes and you need the OOM context to sit on the same lock as the victim to form a deadlock. So while the victim might be blocked somewhere it is much less likely it would be deadlocked.
Since oom_kill_process() sets TIF_MEMDIE on first mm!=NULL thread of a victim process, it is possible that non-first mm!=NULL thread triggers pagefault_out_of_memory() and first mm!=NULL thread gets TIF_MEMDIE, isn't it?
I got lost here completely. Maybe it is your usage of thread terminology again.
Then, where is the guarantee that victim1 (first mm!=NULL thread in memcg1 which got TIF_MEMDIE) is not waiting at down_read(&victim2->mm->mmap_sem) when victim2 (first mm!=NULL thread in memcg2 which got TIF_MEMDIE) is waiting at down_write(&victim2->mm->mmap_sem)
All threads/processes sharing the same mm are in fact in the same memory cgroup. That is the reason we have owner in the task_struct
or both victim1 and victim2 are waiting on a lock somewhere in memory reclaim path (e.g. mutex_lock(&inode->i_mutex))?
Such waiting has to make a forward progress at some point in time because the lock itself cannot be deadlocked by the memcg OOM context. -- 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>