Thanks for supporting the JSON format too.
> (c) If not, given we don't know how to get us out of the current
> status quo, can this patchseries still be applied, given the
> original complaint was the size of our events-list.h (whereas
The Intel core event lists are far larger even
(and will gr
crickets.
How do we make progress in this area?
(a) can we assume Andi's json format is acceptable? We would like
to know this so we don't have to reformat our data more than once.
(b) Would an acceptable interim resolution the 'download area'
problem be to take Andi's "perf: Add support for fu
Well I'm tired of discussing this. I don't think what you
proposed makes sense, putting 3.4MB[1] of changing blob into perf.
I'll resubmit the JSON parser without the downloader. Then users
have the option to get their own events and use that.
If you don't like that, standard perf just has to st
* Scott Wood wrote:
> On Mon, 2015-02-09 at 21:40 +0100, Andi Kleen wrote:
> > > I'll NAK any external 'download area' (and I told that Andi
> > > before): tools/perf/event-tables/ or so is a good enough
> > > 'download area' with fast enough update cycles.
> >
> > The proposal was to put it
On Mon, Feb 09, 2015 at 09:40:19PM +0100, Andi Kleen wrote:
> > I'll NAK any external 'download area' (and I told that Andi
> > before): tools/perf/event-tables/ or so is a good enough
> > 'download area' with fast enough update cycles.
>
> The proposal was to put it on kernel.org, similar to ho
On Mon, 2015-02-09 at 21:40 +0100, Andi Kleen wrote:
> > I'll NAK any external 'download area' (and I told that Andi
> > before): tools/perf/event-tables/ or so is a good enough
> > 'download area' with fast enough update cycles.
>
> The proposal was to put it on kernel.org, similar to how
> ext
> I'll NAK any external 'download area' (and I told that Andi
> before): tools/perf/event-tables/ or so is a good enough
> 'download area' with fast enough update cycles.
The proposal was to put it on kernel.org, similar to how
external firmware blobs are distributed. CPU event lists
are data sh
* Jiri Olsa wrote:
> On Mon, Feb 09, 2015 at 11:07:38AM +0100, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
> > > > arch/powerpc/perf/e6500-events-list.h | 289
> > > > ++
> > >
> > >
On Mon, Feb 09, 2015 at 11:07:38AM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
> > > arch/powerpc/perf/e6500-events-list.h | 289
> > > ++
> >
> > That's a lot of events to stuff in the k
* Peter Zijlstra wrote:
> On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
> > arch/powerpc/perf/e6500-events-list.h | 289
> > ++
>
> That's a lot of events to stuff in the kernel, would a
> userspace list not be more convenient?
>
> ISTR there bein
On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
> arch/powerpc/perf/e6500-events-list.h | 289
> ++
That's a lot of events to stuff in the kernel, would a userspace list
not be more convenient?
ISTR there being various discussions on providing support f
Make the perf events in e6500 available via sysfs.
$ ls /sys/devices/cpu/events/
branch-instructions
branch-misses
cache-misses
cpu-cycles
instructions
FSL_0_INST_CMPL
FSL_1_INST_CMPL
...
$ cat /sys/devices/cpu/events
12 matches
Mail list logo
