Re: [RFC 4/5] x86, perf: implements lwp-perf-integration (rc1)

Vince Weaver
2011-12-21T13:55:44Z

On Wed, 21 Dec 2011, Ingo Molnar wrote:

>
> * Vince Weaver <vweaver1@eecs.utk.edu> wrote:
>
> Have a look at how the 'perf test' self-test utilizes RDPMC in
> these commits in tip:perf/fast:

I did. How many times do I have to tell you I already applied, ran, and
benchmarked this code already, and the results were posted on that link in
the previous e-mail.

> You can find these commits in today's -tip. Overhead should be
> somewhere around 50 cycles per call (i suspect it could
> optimized more), which is a fraction of what a syscall is
> costing.

No, it's more than a "50-cycle" call. To get a value out you need to do
two rdpmc calls plus some mucking about with some mmap'd values. It still
benchmarks much slower than the perctr implementation.

I'd be glad to see _actual_ numbers for an _actual_ test that measures
useful values. Until then I'm believing the numbers I measure on three
different architectures which still show that perf_event has high
overhead.

> > [...] but that's mainly because as-posted the documentation
> > for how to use that patchset is a bit unclear.
>
> In your world there's always someone else to blame.

Yes. I was blaming myself for not understanding the code well enough to
write a good benchmark.

> The thing is, *you* are interested in this niche feature, PeterZ
> not so much.

The thing *we* are interested in is the main PAPI use case. It's arguable
that more people use PAPI under Linux than actually use perf.

> You made a false claim that perf cannot use RDPMC and PeterZ has
> proven you wrong once again. Your almost non-stop whining and
> the constant misrepresentations you make are not very
> productive.

I made no such claim. Please cite.

You made the questionable claim that the AMD devels didn't consult with
any competent perf counter experts. What you meant was that they didn't
have foresight 5 years that Ingo Molnar would come in late with some NIH
implementation of some niche kernel functionality and take it over.
Though in retrospect I guess that's inevitable.

Vince