lkml.org 
[lkml]   [2011]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC][PATCH 0/5] Signal scalability series
    On Tue, Oct 4, 2011 at 10:14 AM, Oleg Nesterov <oleg@redhat.com> wrote:
    >
    > Whatever we do with the locking, this can't remove O(nr_threads),
    > although read_lock() could help to reduce the contention.

    Read locks often make things worse.

    Yes, they allow "more concurrency" and avoid contention, but when
    we're talking spinning read-locks, almost every time we've used them
    we've found them to be *worse* than spinlocks in actual practice.

    Why? One reason is that they are just fundamentally more expensive - a
    spinlock is just simpler. As a practical example, a spinlock can do
    the unlock without the locked cycle.

    The other reason seems to be that they often cause more cacheline
    bouncing on both the lock itself and the data it protects. For a
    spinlock, it's often appropriate to just be exclusive so that you
    basically "concentrate" the accesses to one CPU.

    It's different for the sleeping rw-semaphores of course. There,
    read-locks have major advantages, and if you actually end up having
    sleeping entities, read-locks can be a huge huge improvement over a
    regular mutex, and the "more concurrency" is a big advantage.

    But the spinning rwlock should generally be avoided. The only *real*
    reason for using it is if you have timers/interrupts that can take
    things for reading, and using an rwlock means that most users can then
    avoid the irq save/restore. That pattern improvement more than makes
    up for the fact that the rwlock itself is more expensive than the
    spinlock.

    Almost every time you want to use an rwlock and you think you have a
    lot of readers, you should start looking at RCU instead. Because
    *that* can be a huge improvement over spinlocks.

    Linus


    \
     
     \ /
      Last update: 2011-10-04 19:57    [W:0.022 / U:91.084 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site