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

[David Rientjes <rientjes@google.com>]

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

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