Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760599Ab0KRVTz (ORCPT ); Thu, 18 Nov 2010 16:19:55 -0500 Received: from mail-ew0-f46.google.com ([209.85.215.46]:45517 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759939Ab0KRVTy (ORCPT ); Thu, 18 Nov 2010 16:19:54 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=C2KSY2Fgb93bDAn7lxmkvpNKRbf04xDvMO7Z07HVaDwL+fpBTwaJxigUS+hGGjMv9U Al79D9z44ZlLrRGMc6uhBjxmODYlhODDIGTriq/R+pCX+vKS+rjRdw1lgwW09zgMtgy7 WVjv0/ag5Qm27me3+ipsYZdKroB+urnRaRfs8= Date: Fri, 19 Nov 2010 00:19:49 +0300 From: Cyrill Gorcunov To: Don Zickus Cc: Robert Richter , Jason Wessel , Peter Zijlstra , Ingo Molnar , ying.huang@intel.com, Andi Kleen , LKML , Frederic Weisbecker Subject: Re: [V2 PATCH 0/6] x86, NMI: give NMI handler a face-lift Message-ID: <20101118211949.GG6028@lenovo> References: <4CE2E3C3.6060800@windriver.com> <20101118080516.GJ32621@elte.hu> <4CE52048.5080802@windriver.com> <1290086232.2109.1507.camel@laptop> <20101118193247.GF18100@redhat.com> <4CE583D0.8050407@windriver.com> <20101118200807.GC8131@redhat.com> <20101118202850.GD6028@lenovo> <20101118203948.GE6028@lenovo> <20101118210231.GB11445@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101118210231.GB11445@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1803 Lines: 46 On Thu, Nov 18, 2010 at 04:02:31PM -0500, Don Zickus wrote: ... > > > Don, Robert, > > > > > > I still have suspicious on ours 'pending' nmi handler. Look what I mean -- > > > (keep in mind that p4 has a a way more counters than others). > > > > > > > To be precise -- it seems this scenario may force the back-to-back > > nmi handler to eat unknown nmi. > > That was the point of the change to do exactly that. I missed the word, I meant to eat 'real' unknown nmi, not those generated by counters and stand 'in-fly', so that unknown_nmi_error() will be eaten. what is worse the NMI generated by kgdb may be eaten as well and treated as being 'pending' one, though there is quite a small probability of such situation I believe. > > The problem is/was when you go to check to see if the period expired in > x86_perf_event_set_period(), you refresh the perf counter. The next step > is to see if the event period has expired, if so disabled the 'active' > bit. > > However, there is a race between when you refresh the counter to when you > actually disable it, such that you may cause the counter to overflow again > and thus generate another NMI. The whole ->running thing was implemented > by Robert to try and check for that condition and eat the NMI as we have > no intention of handling it (because it is bogus). > > The alternative is to use another rdmsrl to actually see if we trigger > another NMI. This was deemed a performance hit for such a small case. > > Cheers, > Don > yeah, I recall now, thanks for refresh Don! Cyrill -- 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/