On Thu, 2008-01-31 at 07:10 -0500, Mathieu Desnoyers wrote: > * Steven Rostedt ([EMAIL PROTECTED]) wrote: > > From: John Stultz <[EMAIL PROTECTED]> > > > > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
