Prev: [RFC] oom-kill: give the dying task a higher priority
Next: [PATCH 1/2 v2] FLAT: split the stack & data alignments
From: Peter Zijlstra on 3 Jun 2010 04:00 On Wed, 2010-06-02 at 14:11 -0700, David Rientjes wrote: > > And that can reduce the runtime of the thread holding a writelock on > mm->mmap_sem, making the exit actually take longer than without the patch > if its priority is significantly higher, especially on smaller machines. /me smells an inversion... on -rt we solved those ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Rientjes on 3 Jun 2010 16:40
On Thu, 3 Jun 2010, Peter Zijlstra wrote: > > And that can reduce the runtime of the thread holding a writelock on > > mm->mmap_sem, making the exit actually take longer than without the patch > > if its priority is significantly higher, especially on smaller machines. > > /me smells an inversion... on -rt we solved those ;-) > Right, but I don't see how increasing an oom killed tasks priority to a divine priority doesn't impact the priorities of other tasks which may be blocking the exit of that task, namely a coredumper or holder of mm->mmap_sem. This patch also doesn't address how it negatively impacts the priorities of jobs running in different cpusets (although sharing the same cpus) because one cpuset is oom. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |