lkml.org 
[lkml]   [2005]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [ANNOUNCE] ktimers subsystem
    From
    Date
    On Fri, 2005-09-23 at 02:25 +0200, Roman Zippel wrote:
    > > Maybe it would make sense to have the API be in nanoseconds and internally use
    > > 32bit ms for now, and only change to 64bit nanos when we actually move to
    > > sub-ms resolution timers.
    >
    > Actually the decision to use ns has nothing to do with API issues.
    > <linux/jiffies.h> has already a lot of options to specify timeouts for
    > kernel timer. The official userspace API is mostly timespec/timeval.
    > The nsec_t type is an _internal_ type to manage time, so this makes it
    > possible to do something like this:
    >
    > #ifdef CONFIG_HIRES_TIMER
    > typedef u64 ktime_t;
    > #else
    > typedef u32 ktime_t;
    > #endif

    Sure that's possible, but the 32bit storage format has its limitiations
    and it is not possible to keep the code compatible for both use cases.

    Posix timers - both CLOCK_REALTIME and CLOCK_MONOTONIC - can be
    programmed in absolute time. In a 32bit representation with ms
    resolution we can store ~49 days, so we can not fit the value which come
    up from user space wihtout correction/conversion except we limit the use
    cases to 49 days uptime and clock realtime < 49days since the epoch.

    If we can not fit the given value into the internal representation, we
    have to do exactly what the current implementation of clock realtime in
    posix-timers.c has to do. Storing information about xtime / monotonic
    offset, adding the timer to yet another list (abs_list) convert to
    jiffies and in case the clock gets set, run through all the affected
    timers in abs_list recalculate the expiry value and requeue them.

    The idea of ktimers is to use the requested time given by a timespec in
    human time without any corrections, so we actually can avoid the above.

    Also doing time ordered insertion into a list introduces incompabilities
    between 32/64 bit storage formats.

    I carefully waged the necessary quirk load vs. the cleanliness,
    simplicity and robustness of a pure 64 bit implementation. The resulting
    payload for 32bit systems, which is in the range of 1-3 instructions per
    fast path operation (add, sub, compare) is not worth the trouble IMO to
    give up a clean, simple and robust design, which also allows high
    resolution timers with no big change to the base implementation.


    tglx


    -
    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-09-23 08:52    [W:0.023 / U:0.484 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site