On Mon, 8 Feb 2010 22:49:09 -0800 (PST) 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). > 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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>