lkml.org 
[lkml]   [2004]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: CONFIG_SLOW_TIMESTAMPS was Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft
    Andi Kleen wrote:

    > Theodore Ts'o <tytso@mit.edu> writes:
    >
    >>B) When CONFIG_FAST_TIMESTAMPS is enabled, the kernel SHALL provide
    >>the following 2 routines:
    >>
    >> 2.1 void store_timestamp(timestamp_t *t)
    >
    >
    > sched_clock() already exists and does that, although it is a bit confusingly
    > named.

    I'm not familiar with this call - I'll take a look at it.
    Does this replace get_cycles()?

    > Or just use do_gettimeofday() which should be fast - it is used
    > in networking after all.
    Actually, this call was inspired by the networking guys' desire
    to use something besides do_gettimeofday().

    See http://lwn.net/Articles/61269/

    >
    >
    >> 2.2 void timestamp_to_timeval(timestamp_t *t, struct timeval *tv)
    >
    >
    > I don't think this API is a good idea.
    >
    > The obvious way to implement timestamp_t is just store the CPU integrated
    > time stamp counter into it (TSC in x86 terminology). But there are CPUs
    > where the TSC frequency changes when the CPU changes its core frequency
    > for power saving purposes.

    The specification for this is in the context of bootup time.
    See http://tree.celinuxforum.org/pubwiki/moin.cgi/TimingAPISpecification_5fR1
    The spec. acknowledges that changes in clock frequency will be
    problematic for this API, but ignores that in the context
    of use during the bootup sequence, where the clock frequency
    should be stable.

    However, if these calls are used outside of bootup context,
    then cpu frequency changes are something that would have to be
    dealt with. David Miller's proposed solution for this is to
    fall back to do_gettimeofday() when a processor lacks
    adequate features to support this properly. We would probably
    do that same thing in our implementations.

    You acknowledge that newer TSC implementations (and things like
    it on other platforms) now avoid this problem. In the future,
    I think this will be less of a problem. Hopefully the specification
    and discussions like this will help inform other semiconductor
    vendors about desired features for fast timestamp clocks in new
    chips.

    >...
    > Anyways, the only way to avoid this problem would be to not use the
    > CPU TSC, but some external timer that is independent of the CPU
    > frequency (this is sometimes already done to work around other
    > problems). The problem is just that such external timers in the
    > southbridge are usually factor 100 and more slower than an TSC access
    > that can stay inside the CPU, because an access first has to cross the
    > slow CPU front side bus.
    >
    > This would turn your fast time stamp into an extremly slow time stamp.
    Yes. Our preference would be for all chips to provide good TSC-like
    features. Most of the major semiconductor vendors (and SOC makers
    for CE products) are members of the forum. So hopefully we can drill
    this into their brains.

    > You would be probably better of by just using do_gettimeofday(), which
    > actually has a chance to use the TSC sanely and is not really that
    > slow usually.

    As I said above, the idea to decouple the timestamp retrieval from
    the conversion to normalized units came from the suggestion by
    network guys that do_gettimeofday has too much overhead for their
    packet-stamping requirements. In their case, very often the stamps
    are not used, and so they thought it would be nice if the conversion
    of the values into normalized units (as do_gettimeofday does) were
    a separate operation, that could be performed only as needed.

    In the case of instrumentation code, the conversion to normalized
    units (seconds/microseconds) can often be deferred until the
    dump is post-processed in user space. So if it's possible (but
    only if it's possible, mind you :-), then it's nice to separate
    these two operations.

    Instrumentation code is extremely sensitive to the overhead
    introduced by the timing code. Even for code which uses the
    TSC we have seen something like 8% variance in timing of bootup code
    because of the introduction of the instrumentation.

    Another issue with do_gettimeofday() is that it is not available
    as early as we would like in the bootup sequence. This is because
    it requires setup, which usually doesn't happen until setup_arch().
    (I know, this happens pretty soon, but we want to capture everything
    from start_kernel and beyond.)

    Finally, another reason (which is only mentioned very briefly
    in the spec.) for not using do_gettimeofday is that we envision
    instrumentation scenarios where the time measured goes even
    back before start_kernel (that is, it includes the bootloader.

    It is pretty easy to get uniformity of time measurements
    across both firmware and the kernel using a TSC-like feature, because
    the TSC requires no setup. do_gettimeofday() does not have this property.
    Other CPU-external clocks could be configured by firmware, and
    left alone by the kernel, but then read by this API, to achieve
    this objective (of measurement uniformity across the kernel
    start boundary).

    Thanks very much for the feedback. I'll take a look at sched_clock(),
    and, as I said above, we'll probably use do_gettimeofday() for
    architectures where the CPU or platform doesn't have features that
    support our needs.

    The basic idea of this particular feature is to create a standardized
    API available on all platforms that instrumentation system authors
    can rely on to be there. A lot of the very good instrumentation
    systems (LTT, timepegs, kernel function instrumentation) have historically
    relied on TSC reads and many have not been portable to other platforms.
    This specification, and the implementations that we're working on now
    related to it, are intended to help aid in increasing that portability.

    Here' a page of background info, for those interested:
    http://tree.celinuxforum.org/pubwiki/moin.cgi/InstrumentationAPI

    =============================
    Tim Bird
    Architecture Group Co-Chair
    CE Linux Forum
    Senior Staff Engineer
    Sony Electronics
    E-mail: Tim.Bird@am.sony.com
    =============================

    -
    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: 2005-03-22 14:03    [W:3.071 / U:0.284 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site