- Subject: Re: [PATCH 2/3] Introduce percpu rw semaphores
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Date: Sun, 29 Jul 2012 01:13:34 -0400 (EDT)
- Cc: Jens Axboe <axboe@xxxxxxxxx>, Andrea Arcangeli <aarcange@xxxxxxxxxx>, Jan Kara <jack@xxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Jeff Moyer <jmoyer@xxxxxxxxxx>, dm-devel@xxxxxxxxxx, Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, kosaki.motohiro@xxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, lwoodman@xxxxxxxxxx, "Alasdair G. Kergon" <agk@xxxxxxxxxx>
- In-reply-to: <1343508252.2626.13184.camel@edumazet-glaptop>
- References: <Pine.LNX.4.64.1206272226050.22857@file.rdu.redhat.com> <20120628111541.GB17515@quack.suse.cz> <Pine.LNX.4.64.1207152051490.4240@file.rdu.redhat.com> <x49ipdmyz4q.fsf@segfault.boston.devel.redhat.com> <Pine.LNX.4.64.1207181512530.10923@file.rdu.redhat.com> <x49k3xzq3jc.fsf@segfault.boston.devel.redhat.com> <Pine.LNX.4.64.1207281236230.30415@file.rdu.redhat.com> <Pine.LNX.4.64.1207281240270.30415@file.rdu.redhat.com> <1343508252.2626.13184.camel@edumazet-glaptop>
- Reply-to: device-mapper development <dm-devel@xxxxxxxxxx>
On Sat, 28 Jul 2012, Eric Dumazet wrote:
> On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
> > Introduce percpu rw semaphores
> >
> > When many CPUs are locking a rw semaphore for read concurrently, cache
> > line bouncing occurs. When a CPU acquires rw semaphore for read, the
> > CPU writes to the cache line holding the semaphore. Consequently, the
> > cache line is being moved between CPUs and this slows down semaphore
> > acquisition.
> >
> > This patch introduces new percpu rw semaphores. They are functionally
> > identical to existing rw semaphores, but locking the percpu rw semaphore
> > for read is faster and locking for write is slower.
> >
> > The percpu rw semaphore is implemented as a percpu array of rw
> > semaphores, each semaphore for one CPU. When some thread needs to lock
> > the semaphore for read, only semaphore on the current CPU is locked for
> > read. When some thread needs to lock the semaphore for write, semaphores
> > for all CPUs are locked for write. This avoids cache line bouncing.
> >
> > Note that the thread that is locking percpu rw semaphore may be
> > rescheduled, it doesn't cause bug, but cache line bouncing occurs in
> > this case.
> >
> > Signed-off-by: Mikulas Patocka <mpatocka@xxxxxxxxxx>
>
> I am curious to see how this performs with 4096 cpus ?
Each cpu should have its own rw semaphore in its cache, so I don't see a
problem there.
When you change block size, all 4096 rw semaphores are locked for write,
but changing block size is not a performance sensitive operation.
> Really you shouldnt use rwlock in a path if this might hurt performance.
>
> RCU is probably a better answer.
RCU is meaningless here. RCU allows lockless dereference of a pointer.
Here the problem is not pointer dereference, the problem is that integer
bd_block_size may change.
> (bdev->bd_block_size should be read exactly once )
Rewrite all direct and non-direct io code so that it reads block size just
once ...
Mikulas
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
[DM Crypt]
[Fedora Desktop]
[ATA RAID]
[Fedora Marketing]
[Fedora Packaging]
[Fedora SELinux]
[Yosemite Discussion]
[Yosemite Photos]
[KDE Users]
[Fedora Tools]
[Fedora Docs]