Re: [patch 0/9] mutex subsystem, -V4

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/