On Wednesday 14 November 2007 19:37, David Brownell wrote: > On Tuesday 13 November 2007, Nick Piggin wrote:
> > Upstream, all spinlocks prevent preemption. > > I chose my wording carefully though. A preemption point is > more than just a small region where preemption isn't allowed. > > It's one of those where preemption is *INVITED* ... With CONFIG_PREEMPT upstream, that's exactly the same (unless you're considering preempt breaking points, which you don't seem t obe). > Now, in the RT case, I believe the rationale for inviting > preemption when dropping a lock is largely related to the > way priority inversion is handled. When lock contention can > block higher priority activities, dropping the lock must > be able to trigger the relevant activity switch. There is no specific inviting of preemption. The locks are preemptible -- they can be preempted even while being *held* > ... and the raw spinlocks don't support that machinery, > while "normal" spinlocks become inversion-aware mutexes. > > > But these ones > > are raw locks rather than normal locks probably because that > > they are trivially an innermost and correct lock. > > As in the $SUBJECT case, I'd say. > > Although another point is related to "trivial": the data > is being protected through an operation too trivial to be > worth paying for any of that priority logic. A driver shouldn't get to decide that, IMO. And if there is some policy in the -rt tree allowing these decisions, then it's exactly the kind of thing we don't want upsream. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/