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

    * Andi Kleen <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-19 17:25    [W:0.021 / U:123.852 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site