[lkml]   [2005]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Real-Time Preemption and RCU

    * Ingo Molnar <> wrote:

    > * Paul E. McKenney <> wrote:
    > > I have tested this approach, but in user-level scaffolding. All of
    > > these implementations should therefore be regarded with great
    > > suspicion: untested, probably don't even compile. Besides which, I
    > > certainly can't claim to fully understand the real-time preempt patch,
    > > so I am bound to have gotten something wrong somewhere. [...]
    > you dont even have to consider the -RT patchset: if the scheme allows
    > forced preemption of read-side RCU sections on current upstream
    > CONFIG_PREEMPT, then it's perfect for PREEMPT_RT too.

    there's one detail on PREEMPT_RT though (which i think you noticed too).

    Priority inheritance handling can be done in a pretty straightforward
    way as long as no true read-side nesting is allowed for rwsems and
    rwlocks - i.e. there's only one owner of a lock at a time. So PREEMPT_RT
    restricts rwsem and rwlock concurrency: readers are writers, with the
    only exception that they are allowed to 'self-nest'. I.e. things like:


    are still legal. (it's also done quite often.)

    (it is virtually impossible to implement priority inheritance for true
    multi-reader locks in any sane way: i've done it initially and it sucks
    very much. It also fundamentally increases the 'lock-dependent'
    worst-case latencies - imagine 4 readers having to finish first if a
    higher-prio writer comes along. It's insane.)

    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-03-22 14:11    [W:0.022 / U:7.976 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site