Messages in this thread |  | | | Date | Wed, 26 Jan 2011 14:58:01 +0100 | | From | Ingo Molnar <> | | Subject | Re: 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/
|  |