Messages in this thread |  | | | Date | Tue, 4 Aug 2009 16:38:12 +0200 | | From | Ingo Molnar <> | | Subject | Re: [PATCH 0/3] Add walltime support for ring-buffer |
| |
* KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > > > * KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote: > > > > > 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) > > > > That's definitely something we want to enable ASAP. > > > > I'm wondering why a single u64 timestamp is not enough to express > > the full, absolute range of time elapsed since bootup, in > > nanoseconds. > > > > That would make walltime a matter of pretty-printing only - we'd > > have to convert the u64 nsec timestamp into a walltime format, > > right? > > > > In fact we could change all the timestamps to be standardized along > > 'nanoseconds elapsed since 1970' or so - not nanoseconds since the > > last bootup. That still fits just fine within 64 bits - u64 > > nanoseconds has a scope of 500+ years. > > Ah, you are right. thanks correct me. but I think ntp updating > time storing is necessary too.
Yeah. As long as we only save a single u64 into the trace it should all be fine.
There could be periodic samples of <walltime, sched_clock()> saved on a per cpu basis, and thus converting sched_clock() values into walltime unit?
Ingo
|  |