lkml.org 
[lkml]   [2009]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2009-08-04 16:41    [W:0.029 / U:29.680 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site