Messages in this thread | | | Date | Thu, 07 Apr 2005 17:58:40 +1000 | From | Nick Piggin <> | Subject | Re: [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/
| |