Messages in this thread | | | From | Nick Piggin <> | Subject | Re: [patch 2.6.24-rc2 1/3] generic gpio -- gpio_chip support | Date | Wed, 14 Nov 2007 08:08:24 +1100 |
| |
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 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/
| |