> > 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* ...

> 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 arepreemptible -- 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 issome policy in the -rt tree allowing these decisions, thenit's exactly the kind of thing we don't want upsream.-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at http://www.tux.org/lkml/