Messages in this thread | | | Date | Thu, 9 Jan 2014 16:19:57 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH] Perf: Correct Assumptions about Sample Timestamps in Passes |
| |
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.
| |