Re: [numbers] perfmon/pfmon overhead of 17%-94%

[Ingo Molnar <mingo@elte.hu>]

* Vince Weaver <vince@deater.net> wrote:

>> workloads? [ In fact in one of the scheduler-tests perfmon has a 
>> whopping measurement overhead of _nine billion_ cycles, it 
>> increased total runtime of the workload from 3.3 seconds to 6.6 
>> seconds. (!) ]
>
> I'm sure the perfmon2 people would welcome any patches you have to 
> fix this problem.

I think this flaw of perfmon is unfixable, because perfmon (by 
design) uses a _way_ too low level and way too opaque and 
structure-less abstraction for the PMU, which disallows the kind of 
high-level optimizations that perfcounters can do.

We werent silent about this - to the contrary. Last November Thomas 
and me _did_ take a good look at perfmon patches (we are maintaining 
the code areas affected by perfmon), we saw that it has unfixable 
problems and came up with objections and later on came up with 
patches that fix these problems: the perfcounters subsystem.

>> That's an about 94% measurement overhead, or about 9.2 _billion_ 
>> cycles overhead on this test-system.
>
> I'm more interested in very CPU-intensive benchmarks.  I ran some 
> experiments with gcc and equake from the spec2k benchmark suite.

The workloads i cited are _all_ 100% CPU-intensive benchmarks:

 - hackbench
 - loop-pipe-1-million

But i could add 'lat_tcp localhost', 'bw_tcp localhost' or sysbench 
to the list - all show very significant overhead under perfmon. 
These are all important workloads and important benchmarks. A kernel 
based performance analysis facility that is any good must handle 
them transparently.

	Ingo