From: Andi Kleen on 24 Jun 2010 07:00 > Right, in that case I would very much prefer the simpler thing I > proposed over all this softirq stuff, we can have the tick process the > callbacks for really broken hardware (perf_events doesn't care since > without a lapic there's no pmi anyway). Ying's approach will work I think. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- 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 24 Jun 2010 07:00 On Thu, 2010-06-24 at 12:52 +0200, Andi Kleen wrote: > > Right, in that case I would very much prefer the simpler thing I > > proposed over all this softirq stuff, we can have the tick process the > > callbacks for really broken hardware (perf_events doesn't care since > > without a lapic there's no pmi anyway). > > Ying's approach will work I think. Right, except that I really dislike it, it touches far too much code for no particular reason. And I really want hardirq context for perf callbacks, some code actually relies on it (I used to have the fallback in the timer softirq and that broke thing at some point). So I'm really opposed to all the softirq molestation as I see no reason to do that at all. -- 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: Andi Kleen on 24 Jun 2010 07:10 > And I really want hardirq context for perf callbacks, some code actually > relies on it (I used to have the fallback in the timer softirq and that Surely that could be fixed? *requiring* hard irq context sounds weird. > broke thing at some point). I have one case that needs to sleep (but only when interrupting user code) They key thing in it really is to switch stacks back to process. -andi -- ak(a)linux.intel.com -- Speaking for myself only. -- 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 24 Jun 2010 07:20 On Thu, 2010-06-24 at 13:08 +0200, Andi Kleen wrote: > > And I really want hardirq context for perf callbacks, some code actually > > relies on it (I used to have the fallback in the timer softirq and that > > Surely that could be fixed? *requiring* hard irq context sounds weird. possibly, but there is no reason what so ever to use softirq here. > > broke thing at some point). > > I have one case that needs to sleep (but only when interrupting user code) > They key thing in it really is to switch stacks back to process. softirq can't sleep either, you need a trampoline anyway. -- 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: Andi Kleen on 24 Jun 2010 07:30
On Thu, Jun 24, 2010 at 01:10:52PM +0200, Peter Zijlstra wrote: > On Thu, 2010-06-24 at 13:08 +0200, Andi Kleen wrote: > > > And I really want hardirq context for perf callbacks, some code actually > > > relies on it (I used to have the fallback in the timer softirq and that > > > > Surely that could be fixed? *requiring* hard irq context sounds weird. > > possibly, but there is no reason what so ever to use softirq here. Ok so going back to the original self-irq patchkit. Unfortunately the other reviewer hated that. How to get out of that deadlock? > > > broke thing at some point). > > > > I have one case that needs to sleep (but only when interrupting user code) > > They key thing in it really is to switch stacks back to process. > > softirq can't sleep either, you need a trampoline anywa Not true, when you interrupt ring 3 it can sleep. You just need to make sure to run on the right stack and fix up any irq counters. Anyways this can be solved in a different way too, it would just fit in there too. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- 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/ |