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

    * Paul E. McKenney <paulmck@us.ibm.com> wrote:

    > 5. Scalability -and- Realtime Response.
    >
    > The trick here is to keep track of the CPU that did the
    > rcu_read_lock() in the task structure. If there is a preemption,
    > there will be some slight inefficiency, but the correct lock will be
    > released, preserving correctness.

    the inefficiency will be larger, because (as explained in a previous
    mail) multiple concurrent owners of the read-lock are not allowed. This
    adds to the overhead of PREEMPT_RT on SMP, but is an intentional
    tradeoff. I dont expect PREEMPT_RT to be used on an Altix :-|

    #5 is still the best option, because in the normal 'infrequent
    preemption' case it will behave in a cache-friendly way. A positive
    effect of the lock serializing is that the callback backlog will stay
    relatively small and that the RCU backlog processing can be made
    deterministic as well (if needed), by making the backlog processing
    thread(s) SCHED_FIFO.

    Ingo
    -
    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:11    [W:0.028 / U:89.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site