| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 26 May 2015 12:54:22 -0700 From: Davidlohr Bueso <dave@...olabs.net> To: Peter Zijlstra <peterz@...radead.org> Cc: oleg@...hat.com, paulmck@...ux.vnet.ibm.com, tj@...nel.org, mingo@...hat.com, linux-kernel@...r.kernel.org, der.herr@...r.at, torvalds@...ux-foundation.org Subject: Re: [RFC][PATCH 0/5] Optimize percpu-rwsem While at it, I'll go ahead and add this triviality. From: Davidlohr Bueso <dave@...olabs.net> Date: Tue, 26 May 2015 12:51:15 -0700 Subject: [PATCH] doc,locking: Move percpu-rwsem doc into proper subdir Signed-off-by: Davidlohr Bueso <dbueso@...e.de> --- Documentation/locking/percpu-rw-semaphore.txt | 27 +++++++++++++++++++++++++++ Documentation/percpu-rw-semaphore.txt | 27 --------------------------- 2 files changed, 27 insertions(+), 27 deletions(-) create mode 100644 Documentation/locking/percpu-rw-semaphore.txt delete mode 100644 Documentation/percpu-rw-semaphore.txt diff --git a/Documentation/locking/percpu-rw-semaphore.txt b/Documentation/locking/percpu-rw-semaphore.txt new file mode 100644 index 0000000..7d3c824 --- /dev/null +++ b/Documentation/locking/percpu-rw-semaphore.txt @@ -0,0 +1,27 @@ +Percpu rw semaphores +-------------------- + +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. + +Locking for reading is very fast, it uses RCU and it avoids any atomic +instruction in the lock and unlock path. On the other hand, locking for +writing is very expensive, it calls synchronize_rcu() that can take +hundreds of milliseconds. + +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@...il.com>. +The code was written by Mikulas Patocka <mpatocka@...hat.com> diff --git a/Documentation/percpu-rw-semaphore.txt b/Documentation/percpu-rw-semaphore.txt deleted file mode 100644 index 7d3c824..0000000 --- a/Documentation/percpu-rw-semaphore.txt +++ /dev/null @@ -1,27 +0,0 @@ -Percpu rw semaphores --------------------- - -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. - -Locking for reading is very fast, it uses RCU and it avoids any atomic -instruction in the lock and unlock path. On the other hand, locking for -writing is very expensive, it calls synchronize_rcu() that can take -hundreds of milliseconds. - -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@...il.com>. -The code was written by Mikulas Patocka <mpatocka@...hat.com> -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists