Hi, David. On Tue, Feb 9, 2010 at 3:49 PM, David Rientjes <rientjes@xxxxxxxxxx> 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). My point was following as. We try to kill child of OOMed task at first. But we can't know any locked state of child when OOM happens. It means at this point child is able to be holding any lock. So if we can try to hold task_lock of child, it could make new lock dependency between task_lock and other locks. Although there isn't such lock dependency now, I though it's not good. Please correct me if I was wrong. -- Kind regards, Minchan Kim -- 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