From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754796Ab1I1Rwv (ORCPT ); Wed, 28 Sep 2011 13:52:51 -0400 Received: from claw.goop.org ([74.207.240.146]:38619 "EHLO claw.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753643Ab1I1Rwu (ORCPT ); Wed, 28 Sep 2011 13:52:50 -0400 Message-ID: <4E835EF0.4080200@goop.org> Date: Wed, 28 Sep 2011 10:52:48 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Don Zickus CC: Robert Richter , "x86@kernel.org" , Andi Kleen , Peter Zijlstra , "ying.huang@intel.com" , LKML , "paulmck@linux.vnet.ibm.com" , "avi@redhat.com" Subject: Re: [V6][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs References: <1316805435-14832-1-git-send-email-dzickus@redhat.com> <1316805435-14832-5-git-send-email-dzickus@redhat.com> <20110928103140.GD6063@erda.amd.com> <20110928123720.GL5795@redhat.com> <4E835095.5020706@goop.org> <20110928174400.GS5795@redhat.com> In-Reply-To: <20110928174400.GS5795@redhat.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/28/2011 10:44 AM, Don Zickus wrote: > On Wed, Sep 28, 2011 at 09:51:33AM -0700, Jeremy Fitzhardinge wrote: >> 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. > Right. But I thought this was going to clash with your ticketed spinlock > stuff? To be honest I haven't really been following this thread; it didn't appear to me to relate to the spinlock issue any more. At least in the Xen case, I don't *think* we'll be sending NMIs to domains which are using pv ticketlocks, so the issue is moot. It's more pressing for Avi because he's thinking of using NMIs to implement pv ticketlocks in kvm. J