irq_work
in [Kernel]
|
From: Ingo Molnar on 24 Jun 2010 07:30 * Peter Zijlstra <peterz(a)infradead.org> 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. > > > > 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. What might make sense is to offer two types of callbacks: one that is immediate whenever an event triggers - and another that is sleepable and is executed from process context. Having an intermediate softirq level might be over-design indeed. Thanks, 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 24 Jun 2010 07:40 On Thu, 2010-06-24 at 13:20 +0200, Andi Kleen wrote: > > 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. But that is not softirq. That would be something like what faults do, but we don't have anything else that does that. -- 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:40 On Thu, 2010-06-24 at 13:23 +0200, Ingo Molnar wrote: > What might make sense is to offer two types of callbacks: one that is > immediate whenever an event triggers - and another that is sleepable and is > executed from process context. Trouble is waking that thread, you cannot wake tasks from NMI context, so whatever you do, you'll end up with a trampoline. You could of course offer that trampoline nicely packaged, but I'm not sure that's really worth the effort. -- 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:50 On Thu, 2010-06-24 at 13:20 +0200, Andi Kleen wrote: > Ok so going back to the original self-irq patchkit. Unfortunately the other > reviewer hated that. How to get out of that deadlock? Well, I didn't like your original patch either. What's wrong with going with the patch I posted today? (aside from me getting the barriers slightly wrong and not doing the arch implementation). -- 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 08:00
On Thu, 2010-06-24 at 13:55 +0200, Andi Kleen wrote: > > but we don't have anything else that does that. > > Actually we do, audit in syscalls and scheduling in interrupts and signals > all work this way. Probably more at some point adding more code to this > path was very popular. That's the return to user path, nothing to do with softirqs. Add a TIF flag and call your function there. -- 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/ |