Re: [RFC PATCH 2/9] perf: Add ability to dump user regs

[Stephane Eranian]

On Tue, Oct 19, 2010 at 12:35 AM, Frederic Weisbecker
<fweisbec@xxxxxxxxx> wrote:
> On Mon, Oct 18, 2010 at 12:01:18PM +0200, Stephane Eranian wrote:
>> On Sun, Oct 17, 2010 at 12:07 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>> > On Sat, 2010-10-16 at 00:58 +0200, Frederic Weisbecker wrote:
>> >> > Yes, PEBS does not capture the entire state.
>> >> >
>> >> > Here is what you get on Intel Core:
>> >> > Â Â Â Â u64 flags, ip;
>> >> > Â Â Â Â u64 ax, bx, cx, dx;
>> >> > Â Â Â Â u64 si, di, bp, sp;
>> >> > Â Â Â Â u64 r8, Âr9, Âr10, r11;
>> >> > Â Â Â Â u64 r12, r13, r14, r15;
>> >
>> >> Ok, that seems to cover most of the state. I guess few people care
>> >> about cs, ds, es, fs, gs, most of the time.
>> >
>> > Yeah, except if you want to profile wine or something like that ;-)
>> >
>> That means that if you want the segment registers, then you cannot
>> use PEBS. I think you could catch that when the event is created.
>>
>> The other problem here is how to name registers at the API level.
>> You would be introducing architecture-specific register names
>> in perf_event.h. There is no such a thing today.
>
>
> That can go into an asm/perf_regs.h or something. It's up to the
> arch to name its registers.
>
I am fine with that.

Starting with Nehalem,  there is a PEBS mode where HW captures
not just actual register state but also information about cache misses
such as the data address, miss latency, data source. Those are
stored in the PEBS record as u64. I believe we could also expose
this thru this register bitmask mechanism. Of course, you'd get a
failure if PEBS is not programmed correctly.

The alternative would be to invent yet another generic abstraction
to sample cache misses. Note that PEBS cache miss sampling
cannot be attached to an existing generic cache miss event. It
uses a dedicated event which does not count all cache misses.
--
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/