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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>