Questions about when we take counter measurements, reset, etc

Kyle Huey me at kylehuey.com
Fri Oct 3 17:18:34 PDT 2014


I've been looking at reviving
https://github.com/cgjones/rr/compare/match-up-rbc-irc.  The way we
cache performance counters in Task and reset those, as well as reset
the actual counters we read from is posing some problems.  This
caching/resetting/etc happens at points that don't matter for retired
conditional branches but do matter for instructions retired.  I don't
think I understand things enough to try to rearrange them though.
What's the logic/reasoning behind the points at which we take
measurements, the points at which we reset, etc?

As an alternative, I starting looking into what it would take to move
to just using absolute counter values everywhere, and then we could
throw away caching/resetting/etc entirely.  Did cjones imagine when he
filed #803 that we would switch to using PERF_EVENT_IOC_PERIOD to
reset the signalling mechanism?  The man page[0] is a little
concerning, stating that "Since ... Linux 3.14, the new period takes
effect immediately. On older kernels, the new period did not take
effect until after the next overflow".  The latter could be a problem,
hence my earlier email about the kernel version.  I hacked up using
IOC_PERIOD and it passes most but not all of the tests.  Upgrading my
kernel to 3.14 to see if that fixes the rest was a bit too much for 4
pm on a Friday.

Guidance appreciated!

- Kyle

[0] http://web.eece.maine.edu/~vweaver/projects/perf_events/perf_event_open.html


More information about the rr-dev mailing list