lkml.org 
[lkml]   [2005]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.13-rt6, ktimer subsystem
    Ingo Molnar wrote:
    > i have released the 2.6.13-rt6 tree, which can be downloaded from the
    > usual place:
    >
    > http://redhat.com/~mingo/realtime-preempt/
    >
    > there are lots of small updates all across and there's a big feature as
    > well in this release: a complete rework of the high-resolution timers
    > framework, from Thomas Gleixner, called 'ktimers'.
    >
    > under the ktimer framework the HR (and posix) timers live in a separate
    > domain, have their own (per-CPU) rbtree to stay scalable and
    > deterministic even with a high number of timers. Another positive effect
    > of the introduction of separate ktimers is that kernel/timer.c is now
    > using preemptible locks again, removing the cascade() worst-case
    > latency. The cleanup factor is high as well: the ktimer framework
    > slashes 1300+ lines off the HRT code. See kernel/ktimer.c for details.
    >
    > the end-effect of ktimers is a much more deterministic HRT engine. The
    > original merging of HR timers into the stock timer wheel was a Bad Idea
    > (tm). We intend to push the ktimer subsystem upstream as well.

    Well, having spent a bit of time looking at the code it appears that a
    lot of the ideas we looked at and discarded (see
    high-res-timers-discourse@lists.sourceforge.net) are in this. Shame it
    was all done with out reference or comment to that list, anyone on it or
    even the lkml.

    I DO agree that it _looks_ nicer, cleaner and so on. But there are a
    lot of things we rejected in here and they really do need, at least, a
    hard look.

    A few of the top issues:

    time in nanoseconds 64-bits, requires a divide to do much of anything
    with it. Divides are slow and should be avoided if possible. This is
    especially true in the embedded market.


    The rbtree is a high overhead tree. I suspect performance problems
    here. If it is the right answer here, then why not use it for normal
    timers? A list of timers is a rather unique thing and, I think,
    deserves a management structure that accounts for the fact that the
    elements in the tree are perishable.

    It appears that the "monotonic_clock" is being used to drive ktimers.
    The "monotonic_clock" was NEVER meant to poke outside of the kernel. It
    is a raw kernel clock that is only required to be monotonic with nothing
    said about accuracy. It should NOT be confused with CLOCK_MONOTONIC
    which is directly tied to xtime and therefor is ntp corrected.

    These are only the concerns I have from having a rather quick look at
    the code. I am sure that there are other issues...



    --
    George Anzinger george@mvista.com
    HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
    -
    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-14 21:42    [W:0.024 / U:1.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site