Messages in this thread | | | Date | Fri, 3 Jul 2009 17:25:32 -0400 (EDT) | From | Vince Weaver <> | Subject | Re: [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
| |