On Tue, 2014-11-04 at 01:25 +0000, Andy Lutomirski wrote: > >> 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? > > > > 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. I think I understand where you're coming from. Arnd's idea for the API seems reasonable, although I can't promise implementing a proposal (don't make me stop you from doing it :-). As to the perf-specific correlation, I'm assuming limited accuracy. Others already mentioned that in the absence of hardware support, the time values are never really "atomic". The best what can be done is to access them as near to each other in the code as possible and make sure it happens in a non-preemptible section. In my tests I've achieved, on average, sub-microsecond accuracy, which was good enough from my perspective, but it's far from ideal 42ns resolution for my (just an example) time source clocked at 24MHz. Paweł -- 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
