On Mon, Nov 12, 2012 at 7:53 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:On 11/11/2012 12:32 PM, Stephane Eranian wrote:Yeah, I considered that as well. But it is more complicated. The only syscallOn Sat, Nov 10, 2012 at 3:04 AM, John Stultz <john.stultz@xxxxxxxxxx>
wrote:
Also I worry that it will be abused in the same way that direct TSCThe only goal for this new time source is for correlating user-level
access
is, where the seemingly better performance from the more careful/correct
CLOCK_MONOTONIC would cause developers to write fragile userland code
that
will break when moved from one machine to the next.
samples with
kernel level samples, i.e., application level events with a PMU counter
overflow
for instance. Anybody trying anything else would be on their own.
clock_gettime(CLOCK_PERF): guarantee to return the same time source as
that used by the perf_event subsystem to timestamp samples when
PERF_SAMPLE_TIME is requested in attr->sample_type.
I'm not familiar enough with perf's interfaces, but if you are going to make
this clockid bound so tightly with perf, could you maybe export a perf
timestamp from one of perf's interfaces rather then using the more generic
clock_gettime() interface?
we could extend for perf_events is ioctl(). But that one requires that an
event be created so we obtain a file descriptor for the ioctl() call
So we'd have to
pretend programming a dummy event just for the purpose of obtained a timestamp.
We could do that but that's not so nice. But more amenable to the
Keep in mind that the clock_gettime() would be used by programs which are not
self-monitoring but may be monitored externally by a tool such as perf. We just
need to them to emit their events with a timestamp that can be
correlated offline
with those of perf_events.
Explain to me the key difference between monotonic and what sched_clock()No, of course why we have sched_clock. But I'm suggesting we considerI'd probably rather perf output timestamps to userland using sane clocksCan you get CLOCK_MONOTONIC efficiently and in ALL circumstances without
(CLOCK_MONOTONIC), rather then trying to introduce a new time domain to
userland. But I probably could be convinced I'm wrong.
grabbing any locks because that would need to run from NMI context?
changing what perf exports (via maybe interpolation/translation) to be
CLOCK_MONOTONIC-ish.
is returning today? Does this have to do with the global monotonic vs.
the cpu-wide
monotonic?