Re: [RFC] perf: need to expose sched_clock to correlate user sampleswith kernel samples

From: John Stultz
Date: Wed Apr 03 2013 - 13:57:37 EST


On 04/03/2013 07:22 AM, Stephane Eranian wrote:
On Wed, Apr 3, 2013 at 4:14 PM, David Ahern <dsahern@xxxxxxxxx> wrote:
On 4/3/13 8:00 AM, Stephane Eranian wrote:
Why not have perf convert its
perf_clock timestamps into monotonic or realtime when dumping events?

So this is exactly what I've been wondering through all this.

Perf can keep track of events using its own time domain (which is understandably required due to performance and locking issues), but when exporting those timestamps to userland, could it not do the same (likely imperfect) conversion to existing userland time domains (like CLOCK_MONOTONIC)?


Can monotonic timestamps be obtained from NMI context in the kernel?

I don't understand the context of the question.

I am not suggesting perf_clock be changed. I am working on correlating
existing perf_clock timestamps to clocks typically used by apps (REALTIME
and time-of-day but also applies to MONOTONIC).

But for that, you'd need to expose to users the correlation between
the two clocks.
And now you'd fixed two clock sources definitions not just one.

I'm not sure I follow this. If perf exported data came with CLOCK_MONOTONIC timestamps, no correlation would need to be exposed. perf would just have to do the extra overhead of doing the conversion on export.


You are wanting the reverse -- have apps emit perf_clock timestamps. I was
just wondering what is the advantage of this approach?

Well, that's how I interpreted your question ;-<

If you could have perf_clock use monotonic then we would not have this
discussion.
The correlation would be trivial.

I think the suggestion is not to have the perf_clock use CLOCK_MONOTONIC, but the perf interfaces export CLOCK_MONOTONIC.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/