WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while

To: Don Zickus <dzickus@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking
From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Tue, 13 Sep 2011 23:04:23 +0200
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, Nick Piggin <npiggin@xxxxxxxxx>, KVM <kvm@xxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Andi Kleen <andi@xxxxxxxxxxxxxx>, Avi Kivity <avi@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 13 Sep 2011 14:05:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110913205318.GQ5795@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4E678992.5050709@xxxxxxxxxx> <20110907155657.GX5795@xxxxxxxxxx> <4E679AF4.50209@xxxxxxxxxx> <20110907165203.GQ6838@xxxxxxxxxx> <4E67A551.4000502@xxxxxxxxxx> <20110913184044.GN5795@xxxxxxxxxx> <20110913190320.GR7761@xxxxxxxxxxxxxxxxxx> <20110913192152.GO5795@xxxxxxxxxx> <20110913195838.GS7761@xxxxxxxxxxxxxxxxxx> <20110913205318.GQ5795@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.2i
On Tue, Sep 13, 2011 at 04:53:18PM -0400, Don Zickus wrote:
> On Tue, Sep 13, 2011 at 09:58:38PM +0200, Andi Kleen wrote:
> > > Or are you saying an NMI in an idle system will have the same %rip thus
> > > falsely detecting a back-to-back NMI?
> > 
> > Yup.
> 
> Hmm.  That sucks.  Is there another register that can be used in
> conjunction to seperate it, like sp or something?  Or we can we assume

Not that I know of.

> than an idle cpu isn't doing much for local NMI IPIs and that the only
> NMIs that would interrupt it would be external ones?

There can be still activity on the "idle" system, e.g. SMM or some 
Hypervisor in the background. If you profile events those might trigger 
samples, but they will be all accounted to the MWAIT.

> > Another problem is very long running instructions, like WBINVD and some 
> > others.
> > If there's a high frequency NMI it may well hit multiple times in a single
> >  instance.
> 
> I thought NMIs happen on instruction boundaries, maybe not.

Yes, but there may be multiple queued up when the instruction has finished
executing. So you get multiple at the boundary.

> Honestly, our current implementation would probably be tripped up with
> those examples too, so I don't think I am making things worse (assuming
> the only high frequency NMI is coming from perf).

I wish perf/oprofile would just stop using NMIs.  The interrupt off regions
are getting smaller and smaller and they can be profiled in a limited way
using PEBS anyways. Or maybe make it a knob with default to off.

-Andi


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>