irq_work
in [Kernel]
|
From: Andi Kleen on 24 Jun 2010 08:40 On Thu, Jun 24, 2010 at 02:18:07PM +0200, Peter Zijlstra wrote: > On Thu, 2010-06-24 at 14:02 +0200, Andi Kleen wrote: > > On Thu, Jun 24, 2010 at 01:57:29PM +0200, Peter Zijlstra wrote: > > > 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. > > > > It does that, but there are some cases where it's not enough. > > care to expand on that? This is for execution context error recovery. TIF works for user space, but it's a bit ugly because it requires adding more data to the task_struct because CPUs can change. The sleepable soft irq would have avoided that (that's not a show stopper) The other case was to recover from a *_user() error in the kernel. I originally had some fancy code for preemptive kernels that exploited that you could sleep here (it doesn't work for non preemptive unfortunately because we can't know if locks are hold and some *_user are expected to never sleep) But there were still ugly special cases for switching stacks and the sleepable softirqs could have avoided that. Anyways the later is not fatal either, but it would have been nice to solve that one. -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: Andi Kleen on 24 Jun 2010 09:10 On Thu, Jun 24, 2010 at 02:35:37PM +0200, Ingo Molnar wrote: > All of these solutions use the fact that perf events are a generic event > framework. If there's any missing details somewhere then fixes/enhancements > can be added - right now our in-kernel event consumers are simple. But the > design is sound. One immediate problem that comes to mind with the proposal is that if the event is of a type that cannot be dropped (e.g. an error that needs to be handled) then a shared ring buffer cannot guarantee that. -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: Borislav Petkov on 24 Jun 2010 09:30 From: Andi Kleen <andi(a)firstfloor.org> Date: Thu, Jun 24, 2010 at 03:02:34PM +0200 > On Thu, Jun 24, 2010 at 02:35:37PM +0200, Ingo Molnar wrote: > > All of these solutions use the fact that perf events are a generic event > > framework. If there's any missing details somewhere then fixes/enhancements > > can be added - right now our in-kernel event consumers are simple. But the > > design is sound. > > One immediate problem that comes to mind with the proposal > is that if the event is of a type that cannot be dropped (e.g. an error > that needs to be handled) then a shared ring buffer cannot guarantee that. If its a critical error you do all the handling in the kernel and you don't need task context at all, no? Can you give an example of such an error? -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 -- 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 09:40 > If its a critical error you do all the handling in the kernel and you I assume you mean in MCE. And the answer is no. MCE generally can only panic or log, everything else needs other contexts. > don't need task context at all, no? Process context is needed for various recovery schemes, all that need to sleep for example. -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: Ingo Molnar on 24 Jun 2010 09:50
Andi, * Andi Kleen <andi(a)firstfloor.org> wrote: > > If its a critical error you do all the handling in the kernel and you Sidenote: could you please stop doing this special new email style of cutting out the portion from your emails which shows whom you replied to? Doing that: - Shows disrespect towards the person you are replying to. If you feel the content worth quoting then you should pay respect to the person having written that email as well, and quote his name. - Makes the thread flow much harder to follow to me as i dont see it from the mail text whom you replied to. 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/ |