lkml.org 
[lkml]   [2005]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 4/5] sched: RCU sched domains
    Ingo Molnar wrote:
    > * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
    >
    >
    >>>At a minimum i think we need the fix+comment below.
    >>
    >>Well if we say "this is actually RCU", then yes. And we should
    >>probably change the preempt_{dis|en}ables in other places to
    >>rcu_read_lock.
    >>
    >>OTOH, if we say we just want all running threads to process through a
    >>preemption stage, then this would just be a preempt_disable/enable
    >>pair.
    >>
    >>In practice that makes no difference yet, but it looks like you and
    >>Paul are working to distinguish these two cases in the RCU code, to
    >>accomodate your low latency RCU stuff?
    >
    >
    > it doesnt impact PREEMPT_RCU/PREEMPT_RT directly, because the scheduler
    > itself always needs to be non-preemptible.
    >
    > those few places where we currently do preempt_disable(), which should
    > thus be rcu_read_lock(), are never in codepaths that can take alot of
    > time.
    >
    > but yes, in principle you are right, but in this particular (and
    > special) case it's not a big issue. We should document the RCU read-lock
    > dependencies cleanly and make all rcu-read-lock cases truly
    > rcu_read_lock(), but it's not a pressing issue even considering possible
    > future features like PREEMPT_RT.
    >
    > the only danger in this area is to PREEMPT_RT: it is a bug on PREEMPT_RT
    > if kernel code has an implicit 'spinlock means preempt-off and thus
    > RCU-read-lock' assumption. Most of the time these get discovered via
    > PREEMPT_DEBUG. (preempt_disable() disables preemption on PREEMPT_RT too,
    > so that is not a problem either.)
    >

    OK thanks for the good explanation. So I'll keep it as is for now,
    and whatever needs cleaning up later can be worked out as it comes
    up.

    --
    SUSE Labs, Novell Inc.


    -
    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-04-07 10:02    [W:0.023 / U:36.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site