lkml.org 
[lkml]   [2015]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
> My suggestion to resolve the technical objections and lift the NAK 
> would be:
>
> - to add the tables to the source code, in a more human readable
> format and (optionally) structure the event names better into a
> higher level hierarchy, than the humungous linear dumps with no
> explanations that you propose - while still supporting the 'raw'
> vendor event names you want to use, for those people who are used
> to them.

Trying to understand what you mean with high level hierarchy:

Do you mean something like the oprofile event / unit mask split,
with events having a default unit mask?

This one actually works poorly for modern Intel systems, as
unit masks can completely change the behavior, so there is
not necessarily a direct relation between the name before the dot and the one
after, or a concept of a "default" unit mask.

Or do you mean someone creating a tree hierarchy of events to systematically
debug some particular problem?

I implemented this in my toplev tool here:
https://github.com/andikleen/pmu-tools/wiki/toplev-manual
http://github.com/andikleen/pmu-tools

But it's quite complicated and cannot really be done portable in
a full way without completely turning perf into an architecture specific
tool (which I assume you're opposed to)

Or just some sections grouping events into different topics?
"branches", "caches", "execution" or somesuch.

I think this could be done with the JSON format. Just add a new header.
Print them as sections in perf list.

Or do you mean something like the perf cache events tables?
We already have those. But they cannot replace direct micro architectural
specific events, as the cache event tables do not necessarily express
everything a given micro architecture supports. And also there is a lot
of documentation using the vendor event names, which the users
then want to use.

If it's something else please explain.

>
> - to pre-parse the event descriptions at build time - beyond the
> speedup

FWIW I just measured it and the overhead parse time for the haswell JSON file on
my laptop is about 33ms.

# with event map
% time ./obj-perf/perf list > /dev/null
real 0m0.045s
user 0m0.041s
sys 0m0.003s

% export EVENTMAP=/dev/zero
% time perf list > /dev/null

real 0m0.011s
user 0m0.004s
sys 0m0.006s


> - to upgrade perf as a whole unit: this helps not just your usecase
> but many other usecases as well.

With the downloader it actually automatically downloads any missing
files, so the upgrading just works.

-Andi


\
 
 \ /
  Last update: 2015-04-15 22:01    [W:0.154 / U:9.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site