[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBQiF7OG_rZKkafRuk700ryHi_h_yM7jHh1RLu4k23gW8A@mail.gmail.com>
Date: Tue, 23 Oct 2012 15:58:03 +0200
From: Stephane Eranian <eranian@...gle.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, x86 <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 05/34] perf, x86: Report PEBS event in a raw format
On Tue, Oct 23, 2012 at 3:45 PM, Andi Kleen <andi@...stfloor.org> wrote:
>> I believe we can use a similar approach to PERF_SAMPLE_REGS to expose
>> the PEBS machine state. We need to add PERF_SAMPLE_IREGS and then
>> return interrupt machine registers with regular sampling and the PEBS machine
>> registers in precise mode. A while back I wrote a patch to do just this. Once my
>> PEBS-LL patch is out, I will get back to it.
>
> But why not just use raw? That's far simpler and works fine and is
> already supported by perf script.
>
I have not looked at the scripts. But I am guessing they dump the content of the
PEBS records for further postprocessing by other scripts or programs.
If you do this inside perf, you have access to more infrastructure
code, e.g., dwarf.
For instance, I am interested in getting a value profiling mode. That
means sampling
the values of function arguments. That needs some dwarf support and the PEBS
machine state. With that you can produce a per function histogram of
the 6 integer
register args. You can certainly build anything in Python, but I don't
see the point
of this. Especially given that there is already some infrastructure
(and abstraction)
provided by Jiri's patch for PERF_SAMPLE_REGS.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists