reduce runqueue lock contention
in [Kernel]
|
Prev: [PATCH -mmotm] backlight: fix s6e63m0 kconfig
Next: [PATCH -mmotm] backlight: fix s6e63m0 device attr function return types
From: Peter Zijlstra on 4 Jun 2010 08:10 On Fri, 2010-06-04 at 12:56 +0200, Stijn Devriendt wrote: > The issue I want to tackle is waking up processes when others go to sleep. > This means try_to_wake_up() from inside the runqueue lock. Tejun did something for that: http://lkml.org/lkml/2010/5/13/136 -- 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: Stijn Devriendt on 5 Jun 2010 05:40 On Fri, Jun 4, 2010 at 2:00 PM, Peter Zijlstra <peterz(a)infradead.org> wrote: > On Fri, 2010-06-04 at 12:56 +0200, Stijn Devriendt wrote: > >> The issue I want to tackle is waking up processes when others go to sleep. >> This means try_to_wake_up() from inside the runqueue lock. > > > Tejun did something for that: > > �http://lkml.org/lkml/2010/5/13/136 > > > The difference with what I have is that Tejun's threads are guaranteed to be local and on the same CPU/runqueue avoiding runqueue deadlocks. My code can be used to wake up any thread as I basically defer waking up untill after the runqueue lock is released. -- 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: Peter Zijlstra on 21 Jun 2010 09:10 On Mon, 2010-06-21 at 12:54 +0200, Peter Zijlstra wrote: > > It looses the ttwu task_running() check, as I must admit I'm not quite > > sure what it does.. Ingo? I think I figured out what its for, its for when p is prev in schedule() after deactivate_task(), we have to call activate_task() it again, but we cannot migrate the task because the CPU its on is still referencing it. I added it back, but still fireworks :-) -- 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: Ingo Molnar on 22 Jun 2010 17:20 * Peter Zijlstra <peterz(a)infradead.org> wrote: > So this one boots and builds a kernel on a dual-socket nehalem. > > there's still quite a number of XXXs to fix, but I don't think any of the > races are crashing potential, mostly wrong accounting and scheduling iffies > like. > > But give it a go.. see what it does for you (x86 only for now). > > Ingo, any comments other than, eew, scary? :-) None, other than a question: which future kernel do you aim it for? I'd prefer v2.6.50 or later ;-) This is a truly scary patch. Ingo -- 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: Peter Zijlstra on 23 Jun 2010 05:20
On Tue, 2010-06-22 at 23:11 +0200, Ingo Molnar wrote: > * Peter Zijlstra <peterz(a)infradead.org> wrote: > > > So this one boots and builds a kernel on a dual-socket nehalem. > > > > there's still quite a number of XXXs to fix, but I don't think any of the > > races are crashing potential, mostly wrong accounting and scheduling iffies > > like. > > > > But give it a go.. see what it does for you (x86 only for now). > > > > Ingo, any comments other than, eew, scary? :-) > > None, other than a question: which future kernel do you aim it for? I'd prefer > v2.6.50 or later ;-) Well, assuming it all works out and actually reduces runqueue lock contention we still need to sort out all those XXXs in there, I'd say at the soonest somewhere near .38/.39 or so. Its definitely not something we should rush in. -- 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/ |