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

[Andy Lutomirski]

On Mon, Nov 3, 2014 at 5:11 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> 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.

My only real thought here is that, if perf is going to try to do this,
then presumably it should be reasonably integrated w/ the core timing
code.  I.e. if perf does this, then presumably the core code should
know about it and there should be a core interface to it.

--Andy

>
> thanks
> -john



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/