lkml.org 
[lkml]   [2009]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [numbers] perfmon/pfmon overhead of 17%-94%

> Vince Weaver <vince@deater.net> writes:
>>
>> as I said in a previous post, on most x86 chips the instructions_retired
>> counter also includes any hardware interrupts that occur during the
>> process runtime.
>
> On the other hand afaik near all chips have interrupt performance counter
> events.

I guess by "near all" you mean "only AMD"? The AMD event also has some
oddities, as it seems to report things like page faults and other things
that don't really match up with the excess instruction count. I must
admit it's been a while since I've looked at that particular counter.

> But the question is of course if it's worth it, the error should
> be really small. Also you could always lose a few cycles occasionally
> in other "random" events, which can happen too.

> 1-2 error in a million doesn't sound like a catastrophic problem.

well, it's basically at least HZ extra instructions per however many
seconds your benchmark runs, and unfortunately it's non-deterministic
because it depends on keyboard/network/usb/etc interrupts too that may by
chance happen while your program is running.

For me, it's the determinism that matters. Not overhead, not runtime not
"oh it doesn't matter, it's small". For a deterministic benchmark I
want to get as close to the same value every run as possible. I admit
it might not be possible to always get the same result, but the
closter the better. This might not match up with the way
kernel-hackers use perf counters, but it is important for the work I am
doing.

Vince


\
 
 \ /
  Last update: 2009-07-03 23:17    [W:0.956 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site