Messages in this thread | | | Date | Mon, 3 Nov 2014 17:11:53 -0800 | Subject | Re: [PATCH v3 0/3] perf: User/kernel time correlation and event generation | From | John Stultz <> |
| |
On Mon, Nov 3, 2014 at 4:58 PM, Andy Lutomirski <luto@amacapital.net> wrote: > On Mon, Nov 3, 2014 at 4:28 PM, Pawel Moll <pawel.moll@arm.com> wrote: >> From: Pawel Moll <mail@pawelmoll.com> >> 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
| |