All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Corey Ashford <cjashfor@linux.vnet.ibm.com>,
	Andi Kleen <ak@linux.intel.com>,
	linux-kernel@vger.kernel.org, fweisbec@gmail.com, mingo@elte.hu,
	acme@redhat.com, paulus <paulus@samba.org>
Subject: Re: [PATCH 2/3] perf: Add support for extra parameters for raw events
Date: Fri, 12 Nov 2010 12:36:57 +0100	[thread overview]
Message-ID: <1289561817.2084.240.camel@laptop> (raw)
In-Reply-To: <AANLkTi=idvNVyccD53Xwjp5mWfJb=S8UXekhXNqhzRPC@mail.gmail.com>

On Fri, 2010-11-12 at 11:49 +0100, Stephane Eranian wrote:
> The difficulty with PEBS-LL (load latency) is not so much the encoding of the
> latency. It is more how to expose the data back to user. You get a full PEBS
> record for each miss. So you get the PEBS machine state + data addr, miss
> latency, and data source (where did the line come from). We have already
> discussed how to expose machine state in general. I'll work on a patch for this.

Frederic was working on this PERF_SAMPLE_REGS stuff as well for his copy
the stack top and let dwarfs go wild at it patches.

> So we can get the general PEBS machine state out. However, the question is
> how do we expose data addr, latency, data source? We can reuse the
> SAMPLE_ADDR for the data address. Sample IP would point to the load
> instruction (with help from LBR to correct the off by one issue). For
> the latency

Right, PERF_SAMPLE_IP and PERF_SAMPLE_ADDR 

> and data source, I proposed using pseudo regs and leveraging the sampled machine
> state mechanism. An alternative may be to define a new record type that would b
> generic enough to be reusable, for instance { instr_addr, data_addr,
> latency, data_src, flags; }. 

I'm not sure I like the idea of pseudo regs.. I'm afraid it'll get messy
quite quickly. Load-latency is a bit like IBS that way, terribly messy.



  reply	other threads:[~2010-11-12 11:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11 16:15 [PATCH 1/3] perf-events: Add support for supplementary event registers Andi Kleen
2010-11-11 16:15 ` [PATCH 2/3] perf: Add support for extra parameters for raw events Andi Kleen
2010-11-11 17:54   ` Corey Ashford
2010-11-11 18:39     ` Andi Kleen
2010-11-11 19:38       ` Corey Ashford
2010-11-11 19:49         ` Andi Kleen
2010-11-11 19:59           ` Peter Zijlstra
2010-11-11 20:12             ` Andi Kleen
2010-11-11 20:37               ` Peter Zijlstra
2010-11-12 10:27                 ` Andi Kleen
2010-11-12 10:49                   ` Stephane Eranian
2010-11-12 11:36                     ` Peter Zijlstra [this message]
2010-11-12 13:00                       ` Stephane Eranian
2010-11-12 13:21                         ` Peter Zijlstra
2010-11-12 14:03                           ` Stephane Eranian
2010-11-12 13:30                         ` Frederic Weisbecker
2010-11-12 15:00                           ` Stephane Eranian
2010-11-12 10:41                 ` Stephane Eranian
2010-11-12 10:48                   ` Peter Zijlstra
2010-11-12 10:39             ` Stephane Eranian
2010-11-12 10:48               ` Andi Kleen
2010-11-12 10:52                 ` Stephane Eranian
2010-11-12 10:56                   ` Stephane Eranian
2010-11-11 16:15 ` [PATCH 3/3] perf-events: Fix LLC-* events on Intel Nehalem/Westmere Andi Kleen
2010-11-11 17:35 ` [PATCH/FIX] perf-events: Put the per cpu state for intel_pmu too Andi Kleen
2010-11-11 17:54   ` Stephane Eranian
2010-11-11 18:44     ` Andi Kleen
2010-11-11 21:29       ` Stephane Eranian
2010-11-11 18:06 ` [PATCH 1/3] perf-events: Add support for supplementary event registers Stephane Eranian
2010-11-11 18:42   ` Andi Kleen
2010-11-11 19:09 ` Peter Zijlstra
2010-11-11 19:25   ` Andi Kleen
2010-11-11 19:36     ` Peter Zijlstra
2010-11-11 19:45       ` Andi Kleen
2010-11-11 19:49         ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1289561817.2084.240.camel@laptop \
    --to=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=cjashfor@linux.vnet.ibm.com \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.