On Mon, Nov 3, 2014 at 4:58 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Mon, Nov 3, 2014 at 4:28 PM, Pawel Moll <pawel.moll@xxxxxxx> wrote: >> From: Pawel Moll <mail@xxxxxxxxxxxxx> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
