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

[John Stultz <john.stultz@linaro.org>]

On 04/03/2013 07:22 AM, Stephane Eranian wrote:
> On Wed, Apr 3, 2013 at 4:14 PM, David Ahern <dsahern@gmail.com> 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