Re: [PATCH 06/23 -v8] handle accurate time keeping over long delays

[John Stultz]

On Thu, 2008-01-31 at 07:10 -0500, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@xxxxxxxxxxx) wrote:
> > From: John Stultz <johnstul@xxxxxxxxxx>
> > 
> > Handle accurate time even if there's a long delay between
> > accumulated clock cycles.
> > 
> 
> About this one.. we talked a lot about the importance of timekeeping at
> the first Montreal Tracing Summit this week. Actually, someone
> mentioned a very interesting point : in order to be able to synchronize
> traces taken from the machine with traces taken on external hardware
> (i.e. memory bus tracer on Freescale), taking the "real" counter value
> rather that using the "cumulated cycles" approach (which creates a
> virtual counted instead) would be better.
> 
> So I would recommend using an algorithm that would return a clock value
> which is the same as the underlying hardware counter.

Hmm. It is an interesting issue. Clearly having the raw cycle value
match up so hardware analysis could be mapped to software timestamps
would be useful(although obscure) feature. However with the variety of
clocksources, dealing properly with the clocksource wrap issue (ACPI PM
for instance wraps about every 5 seconds) also has to be addressed.

I think you were mentioning an idea that required some work on the read
side to handle the wraps, basically managing the high order bits by
hand. This sounds like it would be an additional feature that could be
added on to the infrastructure being provided in the
get_monotonic_cycles() patch. No?


However, all of the above is a separate issue then what this (the
timekeeping over long delay) patch addresses, as it is not really
directly related to the get_monotonic_cycles() patch, but instead allows
for correct timekeeping, making update_wall_time() to function properly
if it was deferred for longer then the clocksource's wrap time.

thanks
-john


--
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/