From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754166Ab3A2BAe (ORCPT ); Mon, 28 Jan 2013 20:00:34 -0500 Received: from one.firstfloor.org ([213.235.205.2]:55016 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751342Ab3A2BAc (ORCPT ); Mon, 28 Jan 2013 20:00:32 -0500 Date: Tue, 29 Jan 2013 02:00:29 +0100 From: Andi Kleen To: Stephane Eranian Cc: Andi Kleen , Ingo Molnar , LKML , Peter Zijlstra , Andrew Morton , Arnaldo Carvalho de Melo , Jiri Olsa , Namhyung Kim , Andi Kleen Subject: Re: [PATCH 07/12] perf, x86: Avoid checkpointed counters causing excessive TSX aborts v3 Message-ID: <20130129010029.GY30577@one.firstfloor.org> References: <1359151245-13179-1-git-send-email-andi@firstfloor.org> <1359151245-13179-8-git-send-email-andi@firstfloor.org> <20130128231659.GW30577@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 29, 2013 at 01:30:19AM +0100, Stephane Eranian wrote: > >> The counter is reinstated to its state before the critical section but > >> the PMI cannot be > >> cancelled and there is no state left behind to tell what to do with it. > > > > The PMI is effectively spurious, but we use it to set back. Don't know > > what you mean with "cancel". It already happened of course. > > > But when you do this, it seems you making INT_CP events unusable > for sampling, because you're resetting their value under the cover. > So what happens when you sample, especially with a fixed period? Sampling is forbidden for checkpointed events, the setup code enforces that. It's unlikely to be useful anyways. The main use case for checkpointing is perf stat -T and related counting usages. > >> > >> > + if (event->attr.sample_period > 0 && > >> > + event->attr.sample_period < 0x7fffffff) > >> > + return -EIO; > >> > + } > Explain the 0x7fffffff to me? Is that the max period set by default when you > just count? Originally I had just > 0, but then I found that perf stat from the guest doesn't work anymore because it sets an very high overflow to accumulate counters. The 0x7fffffff is a somewhat arbitary threshold to detect this case. -Andi -- ak@linux.intel.com -- Speaking for myself only.