lkml.org 
[lkml]   [2011]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: perf, x86: Provide a PEBS capable cycle event

    * Stephane Eranian <eranian@google.com> wrote:

    > On Wed, Jan 26, 2011 at 1:06 PM, Ingo Molnar <mingo@elte.hu> wrote:
    > >
    > > * Stephane Eranian <eranian@google.com> wrote:
    > >
    > >> On Wed, Jan 26, 2011 at 12:37 PM, Ingo Molnar <mingo@elte.hu> wrote:
    > >> >
    > >> > * Linux Kernel Mailing List <linux-kernel@vger.kernel.org> wrote:
    > >> >
    > >> >> Gitweb:     http://git.kernel.org/linus/7639dae0ca11038286bbbcda05f2bef601c1eb8d
    > >> >> Commit:     7639dae0ca11038286bbbcda05f2bef601c1eb8d
    > >> >> Parent:     abe43400579d5de0078c2d3a760e6598e183f871
    > >> >> Author:     Peter Zijlstra <a.p.zijlstra@chello.nl>
    > >> >> AuthorDate: Tue Dec 14 21:26:40 2010 +0100
    > >> >> Committer:  Ingo Molnar <mingo@elte.hu>
    > >> >> CommitDate: Thu Dec 16 11:36:44 2010 +0100
    > >> >>
    > >> >>     perf, x86: Provide a PEBS capable cycle event
    > >> >>
    > >> >>     Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    > >> >>     LKML-Reference: <new-submission>
    > >> >>     Signed-off-by: Ingo Molnar <mingo@elte.hu>
    > >> >> ---
    > >> >>  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
    --
    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/

    \
     
     \ /
      Last update: 2011-01-26 15:01    [W:0.042 / U:0.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site