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

On Tue, Nov 4, 2014 at 12:01 AM, Arnd Bergmann [off-list ref] wrote:

On Monday 03 November 2014 17:11:53 John Stultz wrote:

quoted

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