Re: RT patch acceptance

[john cooper]

Andi Kleen wrote:
> What I dislike with RT mutexes is that they convert all locks.
> It doesnt make much sense to me to have a complex lock that
> only protects a few lines of code (and a lot of the spinlock
> code is like this). That is just a waste of cycles.

I had brought this up in the dim past in the context
of adaptive mutexes which could via heuristics decide
whether to spin/sleep.

> But I always though we should have a new lock type that is between
> spinlocks and semaphores and is less heavyweight than a semaphore
> (which tends to be quite slow due to its many context switches). Something
> like a spinaphore, although it probably doesnt need full semaphore
> semantics (rarely any code in the kernel uses that anyways). It could
> spin for a short time and then sleep.

Spin if the lock is contended and the owner is active
on a cpu under the assumption the lock owner's average
hold time is less than that of a context switch.  There
are restrictions as once a path holds an adaptive
mutex as a spin lock it cannot acquire another adaptive
mutex as a blocking lock.

> If you drop irq threads then you cannot convert all locks
> anymore or have to add ugly in_interrupt()checks. So any conversion like
> that requires converting locks.

Yes, I was trying to make that point in an earlier thread.

-john


--
john.cooper@xxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/