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

[Vince Weaver]

On Wed, 21 Dec 2011, Ingo Molnar wrote:

> 
> * Vince Weaver <vweaver1@xxxxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/