All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Huang Ying <ying.huang@intel.com>,
	Fr??d??ric Weisbecker <fweisbec@gmail.com>,
	Don Zickus <dzickus@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC 1/3] Unified NMI delayed call mechanism
Date: Fri, 18 Jun 2010 11:48:38 +0200	[thread overview]
Message-ID: <20100618094838.GD23977@elte.hu> (raw)
In-Reply-To: <4C15A5D1.1040104@jp.fujitsu.com>


* 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 ;-)

> [...]  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

  parent reply	other threads:[~2010-06-18  9:48 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-12  9:28 [RFC 1/3] Unified NMI delayed call mechanism Huang Ying
2010-06-12  9:28 ` [RFC 2/3] Use unified NMI delayed call mechanism in MCE handler Huang Ying
2010-06-12  9:28 ` [RFC 3/3] Use unified NMI delayed call mechanism in perf event NMI handler Huang Ying
2010-06-12 10:25 ` [RFC 1/3] Unified NMI delayed call mechanism Ingo Molnar
2010-06-13  1:54   ` Huang Ying
2010-06-14  3:45   ` Hidetoshi Seto
2010-06-14 13:54     ` Don Zickus
2010-06-14 14:44       ` Andi Kleen
2010-06-14 15:12         ` Don Zickus
2010-06-18 10:30         ` Ingo Molnar
2010-06-18  9:48     ` Ingo Molnar [this message]
2010-06-18 11:34       ` huang ying
2010-06-18 12:45         ` Ingo Molnar
2010-06-18 13:40           ` huang ying
2010-06-18 14:35             ` Ingo Molnar
2010-06-18 15:16               ` huang ying
2010-06-18 15:31                 ` Peter Zijlstra
2010-06-19  1:51                   ` huang ying
2010-06-19  8:02                   ` Andi Kleen
2010-06-19 10:53                     ` Ingo Molnar
2010-06-19 14:07                       ` huang ying
2010-06-19 14:24                       ` Andi Kleen
2010-06-18 11:55 ` Peter Zijlstra
2010-06-18 12:25   ` Andi Kleen
2010-06-18 12:48     ` Peter Zijlstra
2010-06-18 13:09       ` Andi Kleen
2010-06-18 13:12         ` Peter Zijlstra
2010-06-18 13:23           ` Andi Kleen
2010-06-18 13:24             ` Peter Zijlstra
2010-06-18 14:37     ` Ingo Molnar
2010-06-19 14:17       ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100618094838.GD23977@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=dzickus@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=seto.hidetoshi@jp.fujitsu.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.