lkml.org 
[lkml]   [2011]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] perf tools: Add missing user space support for config1/config2
On Tue, 26 Apr 2011, Peter Zijlstra wrote:

> > That's why people use libpfm4. or PAPI. And they do.
>
> And how is typing in hex numbers different from typing in model specific
> event names?

Reall... quick, tell me what event 0x53cf28 corresponds to on a core2.

Now if I said L2_IFETCH:BOTH_CORES you know several things about what it
is.

Plus, you can do a quick search in the Intel Arch manual and find more
info. With the hex value you have to do some shifting and masking by hand
before looking up.

An even worse problem:

Quick... tell me what actual hardware event L1-dcache-loads corresponds
to on an L2. Can you tell without digging through kernel source code?

Does that event include prefetches? Does it include speculative events?
Does it count page walks? Does it overcount by an amount equal to the
number of hardware interrupts? If I use the equivelent event on an
AMD64, will all the same hold?

> PAPI actually has 'generalized' events, but I guess you're going to tell
> me nobody uses those since they're not useful.

Of course people use them. But we don't _force_ people to use them. We
don't disable access to raw events. Although alarmingly it seems like the
kernel is going to start to, possibly meaning even our users can't use our
'generalized' events if for example they incorporate OFFCORE_RESPONSE.

Another issue: if a problem is found with one of the PAPI events, they
can update and recompile and run out of their own account at will.

If there's a problem with a kernel generalized events, you have to
reinstall a kernel. Something many users can't do. For example, your
Nehalem cache fixes will be in 2.6.39. How long until that appears in a
stock distro? How long until that appears in an RHEL release?

> > All the world is not perf.
>
> I know, all the world is interested in investing tons of time learning
> about their one architecture and extract the last few percent of
> performance.

There are people out there who have been using perf counters on UNIX/Linux
machines for decades. They know what events they want to measure. They
are not interested in having the kernel tell them they can't do it.

> I looks like you're all so stuck in your HPC/lowlevel way of things
> you're not even realizing there's much more to be gained by providing
> easy and useful tools to the general public, stuff that works similarly
> across architectures.

We're not saying people can't use perf. Who knows, maybe PAPI will go
away becayse perf is so good. It's just silly to block out access to RAW
events on the argument that "it's too hard". Again, are we Microsoft
here?

> Very constructive attitude, instead of helping you simply subvert and
> route around, thanks man!

I spent a lot of time trying to fix P4 support back in the 2.6.35 days.
I only have so much time to spend on this stuff.

When people complain about p4 support, I direct them to Cyrill et al. I
can't force them to become kernel developers. Usually they want immediate
results, which they can get with perfctr.

People want offcore response. People want uncore access. People want raw
event access. I can tell them "send a patch to the kernel, it'll
languish in obscurity for years and maybe in 2.6.4x you'll see it". Or
they can have support today with an outside patch. Which do you think
they choose?

> And why is that? is that the lack of userspace rdpmc? That should be
> possible with perf, powerpc actually does that already. Various people
> mentioned wanting to make this work on x86 but I've yet to see a patch.

We at the PAPI project welcome any patches you'd care to contribute to our
project too, to make things better. It goes both ways you know.

Vince


\
 
 \ /
  Last update: 2011-04-26 22:35    [from the cache]
©2003-2011 Jasper Spaans