[lkml]   [2005]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RT patch acceptance
    Andi Kleen wrote:

    >>>What I dislike with RT mutexes is that they convert all locks.
    >>>It doesnt make much sense to me to have a complex lock that
    >>>only protects a few lines of code (and a lot of the spinlock
    >>>code is like this). That is just a waste of cycles.
    >>It is NOT just a few lines of code. Millisecond latencies on high-
    >>powered CPU systems means more code than is probably required to send a
    >>rocket 'round the moon and back.
    > Most spinlocks only protect small code parts. Those that protect
    > larger codes can probably use optionally some different lock.
    > But dont attack it with "one size fits all" locking please.

    I have a question about what sort of RT guarantees people might
    want. Forget specific patches or implementations for a minute.
    I'm genuinely curious, as an uneducated bystander - I want to get
    a bit more background about this.

    Presumably your RT tasks are going to want to do some kind of
    *real* work somewhere along the line - so how is that work provided

    For example, suppose you have preemptible everything, and priority
    inheritance and that's all nice. But the actual time in which
    some thread holds a lock is time that no other thread can take
    that lock either, regardless of its priority.

    So in that sense, if you do hard RT in the Linux kernel, it surely
    is always going to be some subset of operations, dependant on
    exact locking implementation, other tasks running and resource usage,

    Tasklist lock might be a good example off the top of my head - so
    you may be able to send a signal to another process with deterministic
    latency, however that latency might look something like: x + nrproc*y

    It appears to me (uneducated bystander, remember) that a nanokernel
    running a small hard-rt kernel and Linux together might be "better"
    for people that want real realtime.

    Just from the point of view of making the RT kernel as small and easy
    to verify as possible, and not having to provide for general purpose
    non-RT tasks. Then you also get the benefit of not having to make the
    general purpose Linux support hard real time.

    For example, if your RT kernel had something like a tasklist lock, it
    may have an upper limit on the number of processes, or put in restart
    points where lower priority processes drop the lock and restart what
    they were doing if a high prio process one comes along - obviously
    neither solution would fly for the Linux tasklist lock.

    Or have I missed something completely? You RT guys have thought about
    it - so what are some pros of the Linux-RT patch and/or cons of the
    nanokernel approach, please?

    [ And again, please don't say why Ingo's RT patch should go in, I'm
    not talking about any patch, any merging of patches or even that
    some hypothetical patch *shouldn't* go in - even if it does have
    above problem ;) ]

    Thanks very much,
    Send instant messages to your online friends

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-27 08:17    [W:0.050 / U:0.604 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site