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: Don Zickus on 14 Jun 2010 11:20 On Mon, Jun 14, 2010 at 04:44:03PM +0200, Andi Kleen wrote: > > I think the perf event subsytem can log events in NMI context already and > > deliver them to userspace when the NMI is done. This is why I think Ingo > > wants MCE to be updated to sit on top of the perf event subsytem to avoid > > re-invent everything again. > > perf is not solving the problem this is trying to solve. > > > Then again I do not know enough about the MCE stuff to understand what you > > mean when an event comes in but you can't handle it in an NMI-safe > > context. An example would be helpful. > > At least for MCE hwpoison recovery needs to sleep and you obviously cannot sleep in > NMI like context. The way it's done is to first do a self interrupt, then do a work queue > wakeup and finally the sleeping operations. > > perf does not fit into this because it has no way to process such an event > inside the kernel. Ah, makes sense. Thanks for the example. Cheers, Don -- 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 05:50 * Hidetoshi Seto <seto.hidetoshi(a)jp.fujitsu.com> wrote: > (2010/06/12 19:25), Ingo Molnar wrote: > > > > * Huang Ying <ying.huang(a)intel.com> wrote: > > > >> NMI can be triggered even when IRQ is masked. So it is not safe for NMI > >> handler to call some functions. One solution is to delay the call via self > >> interrupt, so that the delayed call can be done once the interrupt is > >> enabled again. This has been implemented in MCE and perf event. This patch > >> provides a unified version and make it easier for other NMI semantic handler > >> to take use of the delayed call. > > > > Instead of introducing this extra intermediate facility please use the same > > approach the unified NMI watchdog is using (see latest -tip): a perf event > > callback gives all the extra functionality needed. > > > > The MCE code needs to be updated to use that - and then it will be integrated > > into the events framework. > > Hi Ingo, > > I think this "NMI delayed call mechanism" could be a part of "the events > framework" that we are planning to get in kernel soon. [...] My request was to make it part of perf events - which is a generic event logging framework. We dont really need/want a second 'events framework' as we have one already ;-) > [...] 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. 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 06:40 * Andi Kleen <andi(a)firstfloor.org> wrote: > > I think the perf event subsytem can log events in NMI context already and > > deliver them to userspace when the NMI is done. This is why I think Ingo > > wants MCE to be updated to sit on top of the perf event subsytem to avoid > > re-invent everything again. > > perf is not solving the problem this is trying to solve. That is why i requested to extend the events backend. That will unify more of the code than the first few steps achieved by these three patches - and offers the functionality to all code that uses the events framework. > [...] > > perf does not fit into this because it has no way to process such an event > inside the kernel. It 'does not fit' into the events backend only if you pretend that it is impossible or undesirable to have a delayed, in-context callback mechanism implemented there. If you look at it more closely you'll notice that in reality it's not only possible but that it is also a pretty natural fit. 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: huang ying on 18 Jun 2010 07:40 Hi, Ingo, On Fri, Jun 18, 2010 at 5:48 PM, Ingo Molnar <mingo(a)elte.hu> wrote: > > * Hidetoshi Seto <seto.hidetoshi(a)jp.fujitsu.com> wrote: > >> (2010/06/12 19:25), Ingo Molnar wrote: >> > >> > * Huang Ying <ying.huang(a)intel.com> wrote: >> > >> >> NMI can be triggered even when IRQ is masked. So it is not safe for NMI >> >> handler to call some functions. One solution is to delay the call via self >> >> interrupt, so that the delayed call can be done once the interrupt is >> >> enabled again. This has been implemented in MCE and perf event. This patch >> >> provides a unified version and make it easier for other NMI semantic handler >> >> to take use of the delayed call. >> > >> > Instead of introducing this extra intermediate facility please use the same >> > approach the unified NMI watchdog is using (see latest -tip): a perf event >> > callback gives all the extra functionality needed. >> > >> > The MCE code needs to be updated to use that - and then it will be integrated >> > into the events framework. >> >> Hi Ingo, >> >> I think this "NMI delayed call mechanism" could be a part of "the events >> framework" that we are planning to get in kernel soon. [...] > > My request was to make it part of perf events - which is a generic event > logging framework. We dont really need/want a second 'events framework' > as we have one already ;-) This patchset is simple and straightforward, it is just a delayed execution mechanism, not another 'events framework'. There are several other NMI users other than perf, should we integrate all NMI users into perf framework? >> [...] 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? 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: Andi Kleen on 18 Jun 2010 08:30
> 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. It's actually quite simple and works well -Andi -- 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/ |