Messages in this thread | | | Date | Fri, 1 Feb 2008 12:02:19 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH 06/23 -v8] handle accurate time keeping over long delays |
| |
* John Stultz (johnstul@us.ibm.com) wrote: > > On Thu, 2008-01-31 at 07:10 -0500, Mathieu Desnoyers wrote: > > * Steven Rostedt (rostedt@goodmis.org) wrote: > > > From: John Stultz <johnstul@us.ibm.com> > > > > > > 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? >
Yup, exactly.
> > 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. >
I agree, that could apply on top of the monotonic cycles patch. It's just a different way to see it : dealing with wrapping TSC bits, returning the LSBs given by the hardware, rather than simply accumulating time. This is what the patch I sent earlier (which I use in LTTng) does. I currently expects 32 LSBs to be given by the hardware, but it would be trivial to extend it to support any given number of hardware LSBs.
Mathieu
> thanks > -john > >
-- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |