^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Percpu rw semaphores
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) Percpu rw semaphores is a new read-write semaphore design that is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) optimized for locking for reading.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) The problem with traditional read-write semaphores is that when multiple
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) cores take the lock for reading, the cache line containing the semaphore
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) is bouncing between L1 caches of the cores, causing performance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) degradation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) Locking for reading is very fast, it uses RCU and it avoids any atomic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) instruction in the lock and unlock path. On the other hand, locking for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) writing is very expensive, it calls synchronize_rcu() that can take
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) hundreds of milliseconds.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) The lock is declared with "struct percpu_rw_semaphore" type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) The lock is initialized percpu_init_rwsem, it returns 0 on success and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) -ENOMEM on allocation failure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) The lock must be freed with percpu_free_rwsem to avoid memory leak.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) The lock is locked for read with percpu_down_read, percpu_up_read and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) for write with percpu_down_write, percpu_up_write.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) The idea of using RCU for optimized rw-lock was introduced by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) Eric Dumazet <eric.dumazet@gmail.com>.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) The code was written by Mikulas Patocka <mpatocka@redhat.com>