public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Don Zickus <dzickus@redhat.com>
Cc: Robert Richter <robert.richter@amd.com>,
	"x86@kernel.org" <x86@kernel.org>,
	Andi Kleen <andi@firstfloor.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"ying.huang@intel.com" <ying.huang@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [V6][PATCH 4/6] x86, nmi:  add in logic to handle multiple events and unknown NMIs
Date: Wed, 28 Sep 2011 09:51:33 -0700	[thread overview]
Message-ID: <4E835095.5020706@goop.org> (raw)
In-Reply-To: <20110928123720.GL5795@redhat.com>

On 09/28/2011 05:37 AM, Don Zickus wrote:
> On Wed, Sep 28, 2011 at 12:31:40PM +0200, Robert Richter wrote:
>> On 23.09.11 15:17:13, Don Zickus wrote:
>>> @@ -89,6 +89,15 @@ static int notrace __kprobes nmi_handle(unsigned int type, struct pt_regs *regs)
>>>  
>>>  		handled += a->handler(type, regs);
>>>  
>>> +		/*
>>> + 		 * Optimization: only loop once if this is not a 
>>> + 		 * back-to-back NMI.  The idea is nothing is dropped
>>> + 		 * on the first NMI, only on the second of a back-to-back
>>> + 		 * NMI.  No need to waste cycles going through all the
>>> + 		 * handlers.
>>> + 		 */
>>> +		if (!b2b && handled)
>>> +			break;
>> I don't think we can leave this in. As said, there are cases that 2
>> nmis trigger but the handler is called only once. Only the first would
>> be handled then, and the second get lost cause there is no 2nd nmi
>> call.
> Right.  Avi, Jeremy what was your objection that needed this optimization
> in the first place?

My only interest in the NMI code is its use of spinlocks, which seem
inappropriate.

    J

  reply	other threads:[~2011-09-28 17:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-23 19:17 [V6][PATCH 0/6] x86, nmi: new NMI handling routines Don Zickus
2011-09-23 19:17 ` [V6][PATCH 1/6] x86, nmi: split out nmi from traps.c Don Zickus
2011-09-23 19:17 ` [V6][PATCH 2/6] x86, nmi: create new NMI handler routines Don Zickus
2011-09-23 19:17 ` [V6][PATCH 3/6] x86, nmi: wire up NMI handlers to new routines Don Zickus
2011-09-30 14:25   ` Robert Richter
2011-09-23 19:17 ` [V6][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs Don Zickus
2011-09-26  8:59   ` Peter Zijlstra
2011-09-26 12:55     ` Don Zickus
2011-09-28 10:31   ` Robert Richter
2011-09-28 12:37     ` Don Zickus
2011-09-28 16:51       ` Jeremy Fitzhardinge [this message]
2011-09-28 17:44         ` Don Zickus
2011-09-28 17:52           ` Jeremy Fitzhardinge
2011-10-02 10:07       ` Avi Kivity
2011-10-02 13:48         ` Andi Kleen
2011-10-02 14:04           ` Avi Kivity
2011-10-03 13:13         ` Don Zickus
2011-09-23 19:17 ` [V6][PATCH 5/6] x86, nmi: track NMI usage stats Don Zickus
2011-09-23 19:17 ` [V6][PATCH 6/6] x86, nmi: print out NMI stats in /proc/interrupts Don Zickus

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=4E835095.5020706@goop.org \
    --to=jeremy@goop.org \
    --cc=andi@firstfloor.org \
    --cc=avi@redhat.com \
    --cc=dzickus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=robert.richter@amd.com \
    --cc=x86@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox