From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753365Ab1AZN6T (ORCPT ); Wed, 26 Jan 2011 08:58:19 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:46311 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753098Ab1AZN6S (ORCPT ); Wed, 26 Jan 2011 08:58:18 -0500 Date: Wed, 26 Jan 2011 14:58:01 +0100 From: Ingo Molnar To: Stephane Eranian Cc: Linux Kernel Mailing List , Arnaldo Carvalho de Melo , Peter Zijlstra , Thomas Gleixner , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , Eric Dumazet Subject: Re: perf, x86: Provide a PEBS capable cycle event Message-ID: <20110126135801.GA30064@elte.hu> References: <201101062000.p06K0ESw011195@hera.kernel.org> <20110126113740.GA13911@elte.hu> <20110126120646.GA20064@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Stephane Eranian wrote: > On Wed, Jan 26, 2011 at 1:06 PM, Ingo Molnar wrote: > > > > * Stephane Eranian wrote: > > > >> On Wed, Jan 26, 2011 at 12:37 PM, Ingo Molnar wrote: > >> > > >> > * Linux Kernel Mailing List wrote: > >> > > >> >> Gitweb:     http://git.kernel.org/linus/7639dae0ca11038286bbbcda05f2bef601c1eb8d > >> >> Commit:     7639dae0ca11038286bbbcda05f2bef601c1eb8d > >> >> Parent:     abe43400579d5de0078c2d3a760e6598e183f871 > >> >> Author:     Peter Zijlstra > >> >> AuthorDate: Tue Dec 14 21:26:40 2010 +0100 > >> >> Committer:  Ingo Molnar > >> >> CommitDate: Thu Dec 16 11:36:44 2010 +0100 > >> >> > >> >>     perf, x86: Provide a PEBS capable cycle event > >> >> > >> >>     Signed-off-by: Peter Zijlstra > >> >>     LKML-Reference: > >> >>     Signed-off-by: Ingo Molnar > >> >> --- > >> >>  arch/x86/kernel/cpu/perf_event_intel.c |   26 ++++++++++++++++++++++++++ > >> >>  1 files changed, 26 insertions(+), 0 deletions(-) > >> > > >> > btw., precise profiling via PEBS: > >> > > >> >  perf record -e cycles:p ... > >> > > >> > works pretty nicely now on Nehalem CPUs and later. > >> > > >> The problem is that cycles:p is not equivalent to cycles in terms of how > >> cycles are counted. cycles counts only unhalted cycles. cycles:p counts > >> ALL cycles, event when the CPU is in halted state. > > > > That's not really an issue in practice: it at most can cause a bit larger value for: > > > >     2.38%       swapper  [kernel.kallsyms]      [k] mwait_idle_with_hints                             ▮ > > > > Which entry exists with regular cycles event _anyway_, because every irq entry ends > > up there. > > > > There is a difference in interpretation. Because now when you get samples in those > idle routines, you cannot tell whether it is because you actually execute code > there or because you were halted (not executing) and now sampling has altered the > behavior of the system in that you wake up from halted state to service a PMU > interrupt. The thing is, most people are not interested in seeing the idle routine entry anyway, so we already exclude it in say 'perf top' output, see the skip_symbols[] array in builtin-top.c. So utility seems rather low. If we contrast it to the utility of having precise PEBS sampling, which dramatically improves *all* profiling data and which improves the reading of annotated profiling output beyond measure, the default path to go here seems rather obvious. Agreed? Thanks, Ingo