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