From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753841AbbC3UHN (ORCPT ); Mon, 30 Mar 2015 16:07:13 -0400 Received: from casper.infradead.org ([85.118.1.10]:36819 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753806AbbC3UHJ (ORCPT ); Mon, 30 Mar 2015 16:07:09 -0400 Date: Mon, 30 Mar 2015 22:07:10 +0200 From: Peter Zijlstra To: "Liang, Kan" Cc: Andi Kleen , "linux-kernel@vger.kernel.org" , "mingo@kernel.org" , "acme@infradead.org" , "eranian@google.com" Subject: Re: [PATCH V5 4/6] perf, x86: handle multiple records in PEBS buffer Message-ID: <20150330200710.GO27490@worktop.programming.kicks-ass.net> References: <1424701556-28270-1-git-send-email-kan.liang@intel.com> <1424701556-28270-5-git-send-email-kan.liang@intel.com> <20150330134531.GV23123@twins.programming.kicks-ass.net> <37D7C6CF3E00A74B8858931C1DB2F0770178BAF5@SHSMSX103.ccr.corp.intel.com> <20150330172545.GG2366@two.firstfloor.org> <37D7C6CF3E00A74B8858931C1DB2F0770178BC4D@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F0770178BC4D@SHSMSX103.ccr.corp.intel.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 30, 2015 at 05:43:45PM +0000, Liang, Kan wrote: > As my understanding, Peter means the multiple PEBS bits could be set > when sampling only one single event. > > Peter, could you please clarify? So the chain of events of a PEBS counter is as follows: A) the CTRn value reaches 0: - the corresponding bit in GLOBAL_STATUS gets set - we start arming the hardware assist B) the hardware assist is armed, any next event will trigger it C) a matching event happens: - the hardware assist triggers and generates a PEBS record this includes a copy of GLOBAL_STATUS at this moment - if we auto-reload we (re)set CTRn - we clear the relevant bit in GLOBAL_STATUS CASE 1: Now if we have a chain of events like: A0, B0, A1, C0 The event generated for counter0 will include a status with counter1 set, even though its not at all related to the record. A similar thing can happen with a !PEBS event if it just happens to overflow at the right moment. CASE 2: If otoh we modify things like: A0, B0, A1, B1, C01 Where C01 is an event that triggers both hardware assists (the instruction matches both criteria), we will generate but a single record, but again with both counters listed in the status field. This time the record pertains to both. Note that these two cases are different but undistinguishable with the data as generated -- although one can try and infer given future events. The first case must continue to generate an event for counter1 (hopefully with counter0 clear, otherwise continue with the induction until you get a record with but one set). Also note that its not entirely clear in case two if the event needs to be the very same or just 'close', this is not (well) specified, but conceptually the case presented is the easier.