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? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
