From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752672AbbFKOAs (ORCPT ); Thu, 11 Jun 2015 10:00:48 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:41574 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864AbbFKOAa (ORCPT ); Thu, 11 Jun 2015 10:00:30 -0400 Date: Thu, 11 Jun 2015 16:00:20 +0200 From: Peter Zijlstra To: Alexander Shishkin Cc: Ingo Molnar , linux-kernel@vger.kernel.org, adrian.hunter@intel.com, x86@kernel.org, hpa@zytor.com, acme@infradead.org Subject: Re: [PATCH 2/2] perf/x86/intel: Fix PMI handling for Intel PT Message-ID: <20150611140020.GU19282@twins.programming.kicks-ass.net> References: <1434024837-9916-1-git-send-email-alexander.shishkin@linux.intel.com> <1434024837-9916-3-git-send-email-alexander.shishkin@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1434024837-9916-3-git-send-email-alexander.shishkin@linux.intel.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 11, 2015 at 03:13:57PM +0300, Alexander Shishkin wrote: > @@ -1426,7 +1426,23 @@ perf_event_nmi_handler(unsigned int cmd, struct pt_regs *regs) > u64 finish_clock; > int ret; > > - if (!atomic_read(&active_events)) > + /* > + * Intel PT is a separate PMUs, it doesn't increment active_events > + * nor does it use resources associated with it, such as DS area. > + * However, it still uses the same PMI handler, so here we need > + * to make sure to call it *also* if any PT events are present. > + * > + * BTS events currently increment active_events implicitly through > + * x86_reserve_hardware(), where it acts as DS area reference > + * counter, so no need to check x86_lbr_exclusive_bts counter here; > + * otherwise we'd have to do the same for BTS. > + * > + * Theoretically, they could be made into separate PMI handlers, but > + * that can create additional challenges as PT uses the same PMI status > + * register as x86_pmu. > + */ > + if (!atomic_read(&active_events) && > + !atomic_read(&x86_pmu.lbr_exclusive[x86_lbr_exclusive_pt])) > return NMI_DONE; > Urgh, sad. That's two cache misses instead of one. Cant we somehow keep that a single value to read?