From: Davidlohr Bueso <dave@stgolabs.net>
To: mingo@kernel.org, peterz@infradead.org, oleg@redhat.com
Cc: john.stultz@linaro.org, dimitrysh@google.com,
linux-kernel@vger.kernel.org, dave@stgolabs.net,
Davidlohr Bueso <dbueso@suse.de>
Subject: [PATCH 1/3] locking/percpu-rwsem: Move text file into Documentation/locking/
Date: Fri, 18 Nov 2016 10:54:35 -0800 [thread overview]
Message-ID: <1479495277-9075-2-git-send-email-dave@stgolabs.net> (raw)
In-Reply-To: <1479495277-9075-1-git-send-email-dave@stgolabs.net>
Although this is rather useless and the actual code is orders
of magnitude more detailed and informative than this document.
Might as well keep it instead, I guess its already there and
could give a user a quick why/when use them vs regular rwsems.
Signed-off-by: Davidlohr Bueso <dbueso@suse.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 000000000000..7d3c82431909
--- /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@gmail.com>.
+The code was written by Mikulas Patocka <mpatocka@redhat.com>
diff --git a/Documentation/percpu-rw-semaphore.txt b/Documentation/percpu-rw-semaphore.txt
deleted file mode 100644
index 7d3c82431909..000000000000
--- 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@gmail.com>.
-The code was written by Mikulas Patocka <mpatocka@redhat.com>
--
2.6.6
next prev parent reply other threads:[~2016-11-18 18:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-18 18:54 [PATCH -tip 0/3] locking/percpu-rwsem: writer-side optimizations Davidlohr Bueso
2016-11-18 18:54 ` Davidlohr Bueso [this message]
2016-11-18 18:54 ` [PATCH 2/3] locking/percpu-rwsem: Replace bulky wait-queues with swait Davidlohr Bueso
2016-11-21 12:55 ` Oleg Nesterov
2016-11-21 17:26 ` Davidlohr Bueso
2016-12-03 2:18 ` [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues Davidlohr Bueso
2016-12-05 8:36 ` Peter Zijlstra
2016-12-05 11:26 ` Oleg Nesterov
2016-12-05 11:32 ` Oleg Nesterov
2016-12-05 17:37 ` Davidlohr Bueso
2016-12-05 17:19 ` Oleg Nesterov
2016-12-05 17:13 ` Oleg Nesterov
2016-11-18 18:54 ` [PATCH 3/3] locking/percpu-rwsem: Avoid unnecessary writer wakeups Davidlohr Bueso
2016-11-21 12:23 ` Oleg Nesterov
2016-11-21 12:29 ` Peter Zijlstra
2016-11-21 12:47 ` Oleg Nesterov
2016-11-21 15:07 ` Oleg Nesterov
2016-11-22 3:59 ` Davidlohr Bueso
2016-11-23 14:43 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1479495277-9075-2-git-send-email-dave@stgolabs.net \
--to=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=dimitrysh@google.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®