Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [PATCH 0/3] Add walltime support for ring-buffer | Date | Tue, 28 Jul 2009 11:23:15 +0900 (JST) |
| |
> On Tue, Jul 28, 2009 at 10:43:11AM +0900, KOSAKI Motohiro wrote: > > Hi Zhaolei, > > > > > Hi Zhaolei, > > > > > > Could you not just save the wall time in some 64bit format within the > > > current timestamp? Right now there's three clocks that can be used by > > > ftrace. Two that you can really get two (I need to add access to the > > > third). The default clock is sched_clock. But there's an option to get to > > > global_clock: > > > > > > debug/tracing/options/global-clock > > > > > > # echo 1 > /debug/tracing/options/global-clock > > > > > > Will enable the global clock. Perhaps we can add a "wall clock" version > > > that will map the timestamps to the wall clock? > > > > > > I really hate adding any more fields to the ring buffer headers. That > > > takes away from the amount that you can record per page. > > > > I think wall-time recording on every event is too slow. slower tracer > > isn't useful. > > Instead, Can we make pseudo wall-time recording event periodically? > > > > In nowadays, many workload run on cluster machine environment. Then > > We often need compare different machines tracing log. it mean TSC isn't > > sufficient. but nobody want performance reduce. > > Fortunatelly, ntp time adjustment is not happend so frequently. we > > don't need wall-time on _every_ event. > > > > Thanks. > > > Yeah, that would really slow the tracing. > > Can't we get a snapshot of the couple (walltime, cpu clock) once > at startup. > Then we can retrieve the walltime when cpu_clock was 0 and compute > the walltime for each traces at output time using the trace timestamp as > a delta?
It can. but I don't think it is sufficient. On flight recorder use-case, The tracing run more than one year. And, Administrator only see last N sec log. (previous logs were overwritten by ring-buffer go-around)
Thanks.
| |