On Wed, 2002-07-24 at 09:40, Linus Torvalds wrote:
> Just as an example, in the not too distant future what _will_ happen is
> that
>
> spin_lock_irqsave()
> ..
> spin_unlock_irqrestore()
>
> will not necessarily increment the preemtion count. Why should they?
> They've disabled local interrupts, so there's no preemption to protect
> against. That's just an _obvious_ optimization.
So obvious it is even in my queue :)
I do not think we are ready yet - there is just way too much code that
does not pair up as you mention... but I have played with the patch and
some debugging to see just how feasible it is. Fairly soon.
Note that other preemptible kernels (IRIX and BeOS, for example) do not
even have a preemption count -- all spinlocks also disable interrupts.
Not that I am suggesting that, I am very fond of our preempt_count
mechanism, but its a point to consider even if it were feasible (e.g. we
did not have spinlocks held for hundreds of milliseconds).
> We can easily add a debugging check to spin_unlock() that says:
>
> /* Somebody messed up, doesn't hold any other preemption thing
> * than this lock that is now getting released, and has interrupts
> * disabled
> */
> BUG_ON(preempt_count() == 1 && interrupts_enabled())
>
> No?
Pretty similar to the debugging I played with... as long as it goes away
eventually (who wants this in their unlock path?) we certainly should
add it at some point.
Robert Love
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:16 EST