Re: [PATCH v3 0/3] perf: User/kernel time correlation and event generation

[John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On Tue, Nov 4, 2014 at 12:01 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Monday 03 November 2014 17:11:53 John Stultz wrote:
>> I've got some thoughts on what a possible interface that wouldn't be
>> awful could look like, but I'm still hesitant because I don't really
>> know if exposing this sort of data is actually a good idea long term.
>
> I was also thinking (while working on an unrelated patch) we could use
> a system call like
>
> int clock_getoffset(clockid_t clkid, struct timespec *offs);
>
> that returns the current offset between CLOCK_REALTIME and the
> requested timebase. It is of course racy, but so is every use
> of CLOCK_REALTIME. We could also use a reference other than
> CLOCK_REALTIME that might be more stable, but passing two arbitrary
> clocks as input would make this much more complex to implement.

Yea, this is too racy for me, at least for it to be useful. You get an
offset, but you don't get any sense of what it was actually valid for.

I think to be at all useful, you'll have to return both a timestamp
for a given clockid, and an offset to the second clockid. That way you
can generate a valid point in time on two clocks (as best as possible,
given possible non-atomic reads of separately backed clockids).

But again, I'm not totally sure exposing this provides that much value
over userspace reading the two clocks itself (in ABA fashion) to sort
this out.

And I also don't see it as particularly related to this perf extension
that Pawel is doing (since we are trying to avoid making the perf
clock a directly accessible clockid).

thanks
-john