* Andrew Morton <[email protected]> wrote:
> One side point on semaphores and mutexes: the so-called "fast path" is
> generally not performance-critical, because we just don't take them at
> high frequencies. Any workload which involves taking a semaphore at
> more than 50,000-100,000 times/second tends to have ghastly
> overscheduling failure scenarios on SMP. So people hit those
> scenarios and the code gets converted to a lockless algorithm or to
> use spinlocking.
>
> For example, for a while ext3/JBD was doing 200,000 context-switches
> per second due to taking lock_super() at high frequencies. When I
> converted the whole fs to use spin locking throughout the performance
> in some workloads went up by 1000%.
actually, i'm 99.9% certain [ ;-) ] that all that ext3 spinlock
conversion pain could have been avoided by converting ext3 to the mutex
code. Mutexes definitely do not overschedule, even in very high
frequency lock/unlock scenarios. They behave and perform quite close to
spinlocks. (which property is obviously a must for the -rt kernel, where
all spinlocks, rwlocks, seqlocks, rwsems and semaphores are mutexes -
providing a big playground for locking constructs)
hm, can you see any easy way for me to test my bold assertion on ext3,
by somehow moving/hacking it back to semaphores? I could then apply the
MUTEX_DEBUG_FULL mechanism to it and redo those ext3 semaphore vs.
spinlock benchmarks on a couple of boxes, and add a mutex column to the
table of numbers.
also, often it's simpler to use a sleeping lock than to use a spinlock
for something, so we want to have that option open.
Ingo
-
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]
