[lkml]   [2005]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 4/5] sched: RCU sched domains
Ingo Molnar wrote:
> * Nick Piggin <> 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
>>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
>>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

SUSE Labs, Novell Inc.

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-04-07 10:02    [W:0.053 / U:15.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site