Re: [PATCH 2/3] perf: Add support for extra parameters for raw events

From: Stephane Eranian
Date: Fri Nov 12 2010 - 05:49:25 EST


On Fri, Nov 12, 2010 at 11:27 AM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> On Thu, Nov 11, 2010 at 09:37:38PM +0100, Peter Zijlstra wrote:
>> On Thu, 2010-11-11 at 21:12 +0100, Andi Kleen wrote:
>> > > Also, I think we can use the same mechanism to program the
>> > > PEBS-load-latency MSR, right?
>> >
>> > I haven't looked at that, but if it's a per core resource
>> > the infrastructure can be reused at least.
>>
>> Can't remember if the load-latency msr is per-core, but its an extra reg
>> that needs to be set.
>
> Ok. I guess it shouldn't be too hard to add.
>
> Load-latency is pretty useful too.
>
Yes, it is to figure out where cache misses are.

>>
>> The nhm/wsm LBR config msr is per-core though, so that could use your
>> infrastructure too.
>
> Stephane mentioned that too. Not right now, but perhaps later I'll
> look at using this.
>
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.
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
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; }.

But let's fix OFFCORE_RESPONSE_* first.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/