On Wed, Jan 08, 2014 at 02:48:37PM -0700, David Ahern wrote:The existing code does not work. Your unstable tsc patch did not
work. I have not tried Joseph's patch. Are you proposing that one or
do you have something else in mind?
I think we should integrate Joseph's patch (or mine, or some mixup, I mean
they do about the same IIRC) as it solves known and understood bugs in any case.
Then we need to check what is the real issue in your case.
Now there is still the problem of:
1) local timestamps not moving forward (could it happen when events happen in storm,
when they overflow multiple times in once for example, and clock is not granular
enough?)
Even at 650k events/sec I am not seeing this problem.
Yeah it happens mostly when a single event, supposed to overflow on period of 1, trigger
with a higher period. This is the case of sched stat runtime tracepoints for example
because it is a weighted tracepoint (see perf_count). So it demux into gazillions of
events all having very close timestamps. But normal tracepoints shouldn't have this problem.
Anyway this should be solved with the patch that takes the earliest last event on all
CPU buffer instead of the maximum of a round as a barrier.
2) local timestamps not monotonic due to interrupting events. This could be fixed
in the kernel with moving perf_clock() snapshot in perf_output_sample().
For perf-kvm the events are all tracepoints, so there should not be
a problem of overlap due to interruption.
Nope, I'm curious what kind of issue happens with kvm events. Could you send me a perf.data
that has this ordering problem?