lkml.org 
[lkml]   [2010]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC 1/3] Unified NMI delayed call mechanism
    From
    Hi, Ingo,

    On Fri, Jun 18, 2010 at 5:48 PM, Ingo Molnar <mingo@elte.hu> wrote:
    >
    > * Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> wrote:
    >
    >> (2010/06/12 19:25), Ingo Molnar wrote:
    >> >
    >> > * Huang Ying <ying.huang@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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-06-18 13:37    [W:3.521 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site