lkml.org 
[lkml]   [2005]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/15] Generic Mutex Subsystem

* Andi Kleen <ak@suse.de> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-12-19 17:25    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site