Re: [BUGFIX][PATCH] memcg: fix oom killer kills a task in other cgroup

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Mon, 8 Feb 2010 22:49:09 -0800 (PST)
David Rientjes <rientjes@google.com> wrote:

> On Tue, 9 Feb 2010, Minchan Kim wrote:
> 
> > I think it's not only a latency problem of OOM but it is also a
> > problem of deadlock.
> > We can't expect child's lock state in oom_kill_process.
> > 
> 
> task_lock() is a spinlock, it shouldn't be held for any significant length 
> of time and certainly not during a memory allocation which would be the 
> only way we'd block in such a state during the oom killer; if that exists, 
> we'd deadlock when it was chosen for kill in __oom_kill_task() anyway, 
> which negates your point about oom_kill_process() and while scanning for 
> tasks to kill and calling badness().  We don't have any special handling 
> for GFP_ATOMIC allocations in the oom killer for locks being held while 
> allocating anyway, the only thing we need to be concerned about is a 
> writelock on tasklist_lock, but the oom killer only requires a readlock.  
> You'd be correct if we help write_lock_irq(&tasklist_lock).
> 
Hmm, but it's not necessary to hold task_lock, anyway. Is this patch's logic
itself ok if I rewrite the rescription/comments ?

Thanks,
-Kame

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