Re: [patch 00/15] Generic Mutex Subsystem

[Ingo Molnar]

* Andi Kleen <ak@xxxxxxx> wrote:

> >     $ ./test-mutex V 16 10             $ ./test-mutex V 16 10
> >     8 CPUs, running 16 tasks.          8 CPUs, running 16 tasks.
> >     checking VFS performance.          checking VFS performance.
> >     avg loops/sec:      34713          avg loops/sec:      84153
> >     CPU utilization:    63%            CPU utilization:    22%
> > 
> >    i.e. in this workload, the mutex based kernel was 2.4 times faster 
> >    than the semaphore based kernel, _and_ it also had 2.8 times less CPU 
> >    utilization. (In terms of 'ops per CPU cycle', the semaphore kernel 
> >    performed 551 ops/sec per 1% of CPU time used, while the mutex kernel 
> >    performed 3825 ops/sec per 1% of CPU time used - it was 6.9 times 
> >    more efficient.)
> 
> Do you have an idea where this big difference comes from? It doesn't 
> look it's from the fast path which is essentially the same.  Do the 
> mutexes have that much better scheduling behaviour than semaphores? It 
> is a bit hard to believe.

yes, generic mutexes have that much better scheduling in this workload.  
[ And no, there's no secret speedup magic hidden in the scheduler ;) ] 
See my other reply to Linus about why there's such a difference.

> I would perhaps understand your numbers if you used adaptive mutexes 
> or similar that spin for a bit, but just for pure sleeping locks it 
> seems weird. After all the scheduler should work in the same way for 
> both.

hm, i'm not so sure about adaptive mutexes - i'm a bit uneasy about 
wasting cycles on spinning, it will inevitably cause wasted resources in 
some workloads. I think the right approach is to make scheduling fast 
and cheap, and to improve the queueing/wakeup logic of kernel code.

but by all means feel free to experiment with adaptive mutexes, all the 
mutex logic is located in kernel/mutex.c, and it is well-suited for 
rapid prototyping of new locking logic.

	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/