Re: [RFC][PATCH 0/5] Signal scalability series

[Linus Torvalds]

On Tue, Oct 4, 2011 at 10:14 AM, Oleg Nesterov <oleg@xxxxxxxxxx> 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
--
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/