Re: [PATCH 2/3] perf events: Introduce realtime clock event

[David Ahern <daahern@cisco.com>]

On 02/18/11 07:58, Peter Zijlstra wrote:
>>> I'm really not sure why you want CLOCK_REALTIME and I think
>>> CLOCK_MONOTONIC is more useful (I'd argue you want your system logs to
>>> contain both, every admin who's ever had to untangle what happened
>>> during DST switches will agree)
>>
>> I believe CLOCK_MONOTONIC is what perf_clock is tied to -- the
>> timestamps for PERF_SAMPLE_TIME -- so we already have that.
> 
> Its not (it mere _can_ be), it could be tied to the TSC which can
> significantly drift wrt CLOCK_MONOTONIC.

Ok, either way I would like correlation between perf_clock and the time
sample data and gettimeofday.

> 
>> Programs that generate time-of-day output are using gettimeofday which
>> is tied to CLOCK_REALTIME. We want to be able to correlate a perf sample
>> to an entry in an applications log file.
> 
> Well, you can argue those programs are broken :-), Imagine the joys of
> trying to figure out wth happens when DST jumps the clock back an hour
> and you have an hour of duplicate data.
> 

Luckily DST only happens twice a year. Of course reboots happen a little
more often and those reset the monotonic clock.

I can't change the known universe of programs that create pretty
HH:MM:SS MM/DD/YY time strings. What I do want is to know why a program
missed a heartbeat as noted by a log entry. Correlating with a perf
event and seeing the backtrace is quite handy.

David