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

On Mon, Nov 3, 2014 at 4:58 PM, Andy Lutomirski [off-list ref] wrote:

On Mon, Nov 3, 2014 at 4:28 PM, Pawel Moll [off-list ref] wrote:

quoted

From: Pawel Moll <redacted>
Thomas suggested solution which gets down to my original proposal for
sched/monotonic clock correlation - an additional sample type so events
can be "double stamped" using different clock sources providing
synchronisation points for later time approximation. I've just extended
the implementation with configuration value to select the clock source.
If the first patch (making perf timestamps monotonic) gets accepted,
there will be no immediate need for this one, but I'd like to gain some
feedback anyway.

I have nothing intelligent to add to the potentional Thomas/Ingo
showdown, but I do have a related thought. :)

If you're going to add double-stamped packets, can you also add a
syscall to read multiple clocks at once, atomically?  Or can you
otherwise add a non-perf mechanism to get at this data?

Because the realtime to monotonic offset is really quite useful for
things like this, and it seems silly to make people actually open a
perf_event to get at it.

So this comes up periodically, but I don't think I've seen a interface
proposal that was decent yet.

Also, if you want to read multiple clocks at once, do you stop at two,
or three, or... there's possibly quite a few.  Additionally some
clocks may not be possible to read atomically (perf/sched clock and
system time for example may be based on different underlying
clocksources). The general idea feels like its creeping towards some
"atomically expose all timekeeping state" mega-interface.

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.

thanks
-john