[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 07 Jul 2012 17:27:44 +1000
From: Michael Ellerman <michael@...erman.id.au>
To: Stephane Eranian <eranian@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Feng Tang <feng.tang@...el.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
x86@...nel.org, Andi Kleen <ak@...ux.intel.com>,
Robert Richter <robert.richter@....com>
Subject: Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw
format
On Thu, 2012-07-05 at 17:57 +0200, Stephane Eranian wrote:
> On Wed, Jul 4, 2012 at 11:13 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > I think Stephane is currently trying to revive that, although he hasn't
> > posted yet. Please have a look if that captures the possible PPC states
> > as well. Stephane could you share your current stuff so Michael can have
> > a look?
> I am currently on vacation and with limited internet access.
No stress, I am currently busy doing other things :)
> But yes, the PEBS-LL patchset I have been working on
> does abstract PEBS-LL and offers an abstracted data source
> field. It uses:
> PERF_SAMPLE_IP: for instr address
> PERF_SAMPLE_ADDR: for the data address
>
> It introduces:
> PERF_SAMPLE_LATENCY: to capture the access latency
> PERF_SAMPLE_DSRC: to encode the data source.
>
> That latter value is a structured bitmask which covers:
> - type of access (load, store, prefetch, instr)
> - mem level: hit or miss in L1, LFB, L2, L3, LOC_RAM, REM_RAM, uncached, IO
> - snoop access: hit, miss, none
> - TLB access: hit or miss in L1, L2, HW walker, OS fault
>
> Hopefully those are generic enough to cover all possible cases across
> architectures. PPC would be a good test case.
> Note that multiple bits per category may be set in case the HW cannot
> disambiguate like this is the case on with PEBS-LL sometimes.
OK that sounds promising. And I like that it's a bitmask.
>From a preliminary look I think the list you have above will cover most
of the information we can report. And we should have some bits left over
for extensibility.
cheers
--
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