lkml.org 
[lkml]   [2013]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples
On 03/31/2013 09:23 AM, David Ahern wrote:
> On 3/14/13 1:57 PM, Pawel Moll wrote:
>> Ok, how about the code below? I must say I have some doubts about the
>> resolution, as there seem to be no generic way of figuring it out for
>> the sched_clock (the arch/arm/kernel/sched_clock.c is actually
>> calculating it, but than just prints it out and nothing more).
>>
>> And, to summarize, we went through 3 ideas:
>>
>> 1. ioctl() - http://article.gmane.org/gmane.linux.kernel/1433933
>> 2. syscall - http://article.gmane.org/gmane.linux.kernel/1437057
>> 3. POSIX clock - below
>>
>> John also suggested that maybe the perf could use CLOCK_MONOTONIC_RAW
>> instead of local/sched_clock().
>
> Any chance a decision can be reached in time for 3.10? Seems like the
> simplest option is the perf event based ioctl.

I'm still not sold on the CLOCK_PERF posix clock. The semantics are
still too hand-wavy and implementation specific.

While I'd prefer perf to export some existing semi-sane time domain
(using interpolation if necessary), I realize the hardware constraints
and performance optimizations make this unlikely (though I'm
disappointed I've not seen any attempt or proof point that it won't work).

Thus if we must expose this kernel detail to userland, I think we should
be careful about how publicly we expose such an interface, as it has the
potential for misuse and eventual user-land breakage.

So while having a perf specific ioctl is still exposing what I expect
will be non-static kernel internal behavior to userland, it at least it
exposes it in a less generic fashion, which is preferable to me.



The next point of conflict is likely if the ioctl method will be
sufficient given performance concerns. Something I'd be interested in
hearing about from the folks pushing this. Right now it seems any method
is preferable then not having an interface - but I want to make sure
that's really true.

For example, if the ioctl interface is really too slow, its likely folks
will end up using periodic perf ioctl samples and interpolating using
normal vdso clock_gettime() timestamps.

If that is acceptable, then why not invert the solution and just have
perf injecting periodic CLOCK_MONOTONIC timestamps into the log, then
have perf report fast, but less-accurate sched_clock deltas from that
CLOCK_MONOTONIC boundary.

Another alternative that might be a reasonable compromise: have perf
register a dynamic posix clock id, which would be a driver specific,
less public interface. That would provide the initial method to access
the perf time domain. Then when it came time to optimize further,
someone would have to sort out the difficulties of creating a vdso
method for accessing dynamic posix clocks. It wouldn't be easy, but it
wouldn't be impossible to do.


> Converting/correlating perf_clock timestamps to time-of-day is a
> feature I have been trying to get into perf for over 2 years. This is
> a big piece needed for that goal -- along with the xtime tracepoints:
> https://lkml.org/lkml/2013/3/19/433

I sympathize with how long this process can take. Having maintainers
disagree without resolution can be a tar-pit. That said, its only been a
few months where this has had proper visibility, and the discussion has
paused for months at a time. Despite how long and slow this probably
feels, the idea of maintaining a bad interface for the next decade seems
much longer. ;) So don't get discouraged yet.

thanks
-john


\
 
 \ /
  Last update: 2013-04-01 21:21    [W:0.122 / U:0.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site