[lkml]   [2009]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [numbers] perfmon/pfmon overhead of 17%-94%

* Vince Weaver <> 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.


 \ /
  Last update: 2009-06-30 02:09    [W:0.077 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site