2017-05-16 20:14:12 +07:00
|
|
|
====================
|
blockdev: turn a rw semaphore into a percpu rw semaphore
This avoids cache line bouncing when many processes lock the semaphore
for read.
New percpu lock implementation
The lock consists of an array of percpu unsigned integers, a boolean
variable and a mutex.
When we take the lock for read, we enter rcu read section, check for a
"locked" variable. If it is false, we increase a percpu counter on the
current cpu and exit the rcu section. If "locked" is true, we exit the
rcu section, take the mutex and drop it (this waits until a writer
finished) and retry.
Unlocking for read just decreases percpu variable. Note that we can
unlock on a difference cpu than where we locked, in this case the
counter underflows. The sum of all percpu counters represents the number
of processes that hold the lock for read.
When we need to lock for write, we take the mutex, set "locked" variable
to true and synchronize rcu. Since RCU has been synchronized, no
processes can create new read locks. We wait until the sum of percpu
counters is zero - when it is, there are no readers in the critical
section.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-09-26 12:46:43 +07:00
|
|
|
Percpu rw semaphores
|
2017-05-16 20:14:12 +07:00
|
|
|
====================
|
blockdev: turn a rw semaphore into a percpu rw semaphore
This avoids cache line bouncing when many processes lock the semaphore
for read.
New percpu lock implementation
The lock consists of an array of percpu unsigned integers, a boolean
variable and a mutex.
When we take the lock for read, we enter rcu read section, check for a
"locked" variable. If it is false, we increase a percpu counter on the
current cpu and exit the rcu section. If "locked" is true, we exit the
rcu section, take the mutex and drop it (this waits until a writer
finished) and retry.
Unlocking for read just decreases percpu variable. Note that we can
unlock on a difference cpu than where we locked, in this case the
counter underflows. The sum of all percpu counters represents the number
of processes that hold the lock for read.
When we need to lock for write, we take the mutex, set "locked" variable
to true and synchronize rcu. Since RCU has been synchronized, no
processes can create new read locks. We wait until the sum of percpu
counters is zero - when it is, there are no readers in the critical
section.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-09-26 12:46:43 +07:00
|
|
|
|
|
|
|
Percpu rw semaphores is a new read-write semaphore design that is
|
|
|
|
optimized for locking for reading.
|
|
|
|
|
|
|
|
The problem with traditional read-write semaphores is that when multiple
|
|
|
|
cores take the lock for reading, the cache line containing the semaphore
|
|
|
|
is bouncing between L1 caches of the cores, causing performance
|
|
|
|
degradation.
|
|
|
|
|
2012-09-27 00:56:15 +07:00
|
|
|
Locking for reading is very fast, it uses RCU and it avoids any atomic
|
blockdev: turn a rw semaphore into a percpu rw semaphore
This avoids cache line bouncing when many processes lock the semaphore
for read.
New percpu lock implementation
The lock consists of an array of percpu unsigned integers, a boolean
variable and a mutex.
When we take the lock for read, we enter rcu read section, check for a
"locked" variable. If it is false, we increase a percpu counter on the
current cpu and exit the rcu section. If "locked" is true, we exit the
rcu section, take the mutex and drop it (this waits until a writer
finished) and retry.
Unlocking for read just decreases percpu variable. Note that we can
unlock on a difference cpu than where we locked, in this case the
counter underflows. The sum of all percpu counters represents the number
of processes that hold the lock for read.
When we need to lock for write, we take the mutex, set "locked" variable
to true and synchronize rcu. Since RCU has been synchronized, no
processes can create new read locks. We wait until the sum of percpu
counters is zero - when it is, there are no readers in the critical
section.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-09-26 12:46:43 +07:00
|
|
|
instruction in the lock and unlock path. On the other hand, locking for
|
|
|
|
writing is very expensive, it calls synchronize_rcu() that can take
|
2012-09-27 00:56:15 +07:00
|
|
|
hundreds of milliseconds.
|
blockdev: turn a rw semaphore into a percpu rw semaphore
This avoids cache line bouncing when many processes lock the semaphore
for read.
New percpu lock implementation
The lock consists of an array of percpu unsigned integers, a boolean
variable and a mutex.
When we take the lock for read, we enter rcu read section, check for a
"locked" variable. If it is false, we increase a percpu counter on the
current cpu and exit the rcu section. If "locked" is true, we exit the
rcu section, take the mutex and drop it (this waits until a writer
finished) and retry.
Unlocking for read just decreases percpu variable. Note that we can
unlock on a difference cpu than where we locked, in this case the
counter underflows. The sum of all percpu counters represents the number
of processes that hold the lock for read.
When we need to lock for write, we take the mutex, set "locked" variable
to true and synchronize rcu. Since RCU has been synchronized, no
processes can create new read locks. We wait until the sum of percpu
counters is zero - when it is, there are no readers in the critical
section.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-09-26 12:46:43 +07:00
|
|
|
|
|
|
|
The lock is declared with "struct percpu_rw_semaphore" type.
|
|
|
|
The lock is initialized percpu_init_rwsem, it returns 0 on success and
|
|
|
|
-ENOMEM on allocation failure.
|
|
|
|
The lock must be freed with percpu_free_rwsem to avoid memory leak.
|
|
|
|
|
|
|
|
The lock is locked for read with percpu_down_read, percpu_up_read and
|
|
|
|
for write with percpu_down_write, percpu_up_write.
|
|
|
|
|
|
|
|
The idea of using RCU for optimized rw-lock was introduced by
|
|
|
|
Eric Dumazet <eric.dumazet@gmail.com>.
|
|
|
|
The code was written by Mikulas Patocka <mpatocka@redhat.com>
|