![]() | ||||||||||
Messages in this thread |
On Fri, 1 Feb 2008, Mathieu Desnoyers wrote: > > > > 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. > So you are saying that you can trivally make it work with a clock that is, say 24 bits? And this same code can work if we boot up with a clock with 32 bits or more? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2008-02-02 06:15 [W:0.282 / U:0.450 seconds] ©2003-2008 Jasper Spaans | ||||||||||