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
--
[email protected]
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
