Unified NMI delayed call mechanism
in [Kernel]
|
Prev: mpd client timeouts (bisected) 2.6.35-rc3
Next: 2.6.35-rc{12} regression: inactive console corrupted
From: Andi Kleen on 18 Jun 2010 09:30 On Fri, Jun 18, 2010 at 03:12:49PM +0200, Peter Zijlstra wrote: > On Fri, 2010-06-18 at 15:09 +0200, Andi Kleen wrote: > > > You generally want to pass more information along anyway, now your > > > callback function needs to go look for it. Much better to pass a > > > work_struct like thing around that is contained in the state it needs. > > > > But how would you allocate the work queue in an NMI? > > > > If it's only a single instance (like this bit) it can be always put > > into a per cpu variable. > > Pre-allocate. For the perf-event stuff we use the perf_event allocated > at creation time. But yeah, per-cpu storage also works. So you could just preallocate the bits instead ? -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: huang ying on 18 Jun 2010 09:50 On Fri, Jun 18, 2010 at 8:45 PM, Ingo Molnar <mingo(a)elte.hu> wrote: >> >> [...] ??At least APEI will use NMI to report some hardware events (likely >> >> error) to kernel. ??So I suppose we will go to have a delayed call as an >> >> event handler for APEI. >> > >> > Yep, that makes sense. I wasnt arguing against the functionality itself, i >> > was arguing against the illogical layering that limits its utility. By >> > making it part of perf events it becomes a generic part of that framework >> > and can be used by anything that deals with events and uses that >> > framework. >> >> I think the the 'layering' in the patchset helps instead of 'limits' its >> utility. It is designed to be as general as possible, so that it can be used >> by both perf and other NMI users. Do you think so? > > What other NMI users do you mean? EDAC/MCE is going to go utilize events as > well (away from the horrible /dev/mcelog interface), the NMI watchdog already > did it and the perf tool obviously does as well. There's a few leftovers like > kcrash which isnt really event centric and i dont think it needs to be > converted. But why not just make it more general? It does not hurt anyone including perf. Best Regards, Huang Ying -- 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 18 Jun 2010 10:40 * Andi Kleen <andi(a)firstfloor.org> wrote: > > So aside from the should this be perf or not, the above is utter > > gibberish. Whoever came up with this nonsense? > > This is pretty much how softirqs (and before them bottom halves) work. > I believe Linus invented that scheme originally back in the early > days of Linux. Nope - the softirq code was written by Alexey Kuznetsov and David S. Miller. But it's irrelevant, because: > It's actually quite simple and works well .... as Peter said the last thing we want is yet another softirq vector. 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: Ingo Molnar on 18 Jun 2010 10:40 * huang ying <huang.ying.caritas(a)gmail.com> wrote: > On Fri, Jun 18, 2010 at 8:45 PM, Ingo Molnar <mingo(a)elte.hu> wrote: > >> >> [...] ??At least APEI will use NMI to report some hardware events (likely > >> >> error) to kernel. ??So I suppose we will go to have a delayed call as an > >> >> event handler for APEI. > >> > > >> > Yep, that makes sense. I wasnt arguing against the functionality itself, i > >> > was arguing against the illogical layering that limits its utility. By > >> > making it part of perf events it becomes a generic part of that framework > >> > and can be used by anything that deals with events and uses that > >> > framework. > >> > >> I think the the 'layering' in the patchset helps instead of 'limits' its > >> utility. It is designed to be as general as possible, so that it can be used > >> by both perf and other NMI users. Do you think so? > > > > What other NMI users do you mean? EDAC/MCE is going to go utilize events > > as well (away from the horrible /dev/mcelog interface), the NMI watchdog > > already did it and the perf tool obviously does as well. There's a few > > leftovers like kcrash which isnt really event centric and i dont think it > > needs to be converted. > > But why not just make it more general? It does not hurt anyone including > perf. Because it's not actually more generic that way - just look at the code. It's x86 specific, plus it ties it to NMI delivery while the concept of delayed execution has nothing to do with NMIs. 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: huang ying on 18 Jun 2010 11:20
On Fri, Jun 18, 2010 at 10:35 PM, Ingo Molnar <mingo(a)elte.hu> wrote: > > * huang ying <huang.ying.caritas(a)gmail.com> wrote: > >> On Fri, Jun 18, 2010 at 8:45 PM, Ingo Molnar <mingo(a)elte.hu> wrote: >> >> >> [...] ??At least APEI will use NMI to report some hardware events (likely >> >> >> error) to kernel. ??So I suppose we will go to have a delayed call as an >> >> >> event handler for APEI. >> >> > >> >> > Yep, that makes sense. I wasnt arguing against the functionality itself, i >> >> > was arguing against the illogical layering that limits its utility. By >> >> > making it part of perf events it becomes a generic part of that framework >> >> > and can be used by anything that deals with events and uses that >> >> > framework. >> >> >> >> I think the the 'layering' in the patchset helps instead of 'limits' its >> >> utility. It is designed to be as general as possible, so that it can be used >> >> by both perf and other NMI users. Do you think so? >> > >> > What other NMI users do you mean? EDAC/MCE is going to go utilize events >> > as well (away from the horrible /dev/mcelog interface), the NMI watchdog >> > already did it and the perf tool obviously does as well. There's a few >> > leftovers like kcrash which isnt really event centric and i dont think it >> > needs to be converted. >> >> But why not just make it more general? It does not hurt anyone including >> perf. > > Because it's not actually more generic that way - just look at the code. It's > x86 specific, plus it ties it to NMI delivery while the concept of delayed > execution has nothing to do with NMIs. soft_irq is a delayed mechanism for IRQ, a self interrupt can be a delayed mechanism for NMI. If we can make soft_irq NMI-safe, we can use soft_irq as a backup of self interrupt (for systems without APIC and maybe for other architectures). Best Regards, Huang Ying -- 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/ |