From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, Joe Perches <joe@perches.com>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [RFC PATCH] Writer-biased low-latency rwlock v8
Date: Thu, 21 Aug 2008 14:15:08 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0808211402370.3487@nehalem.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0808211356360.3487@nehalem.linux-foundation.org>
On Thu, 21 Aug 2008, Linus Torvalds wrote:
>
> That leaves 30 bits for readers. If you still think you need to "limit the
> number of readers", then you aren't getting it.
Side note: the actual main rwlock thing is designed for a 64-bit word and
the waiters separately as two 32-bit words, so it doesn't really do what I
describe, but that's actually because the whole sleeping thing is _harder_
than a spinning thing, and has races with wakeups etc.
A spinning thing, in contrast, is pretty trivial.
So here's what I think your code should be like:
rdlock:
movl $4,%eax
lock ; xaddl %eax,(%rdi)
testl $3,%eax
jne __rdlock_slowpath
ret
rwlock:
xorl %eax,%eax
movl $1,%edx
lock ; cmpxchgl %edx,(%rdi)
jne __rwlock_slowpath
ret
rdunlock:
lock ; subl $4,(%rdi)
ret
rwunlock:
lock ; andl $~1,(%rdi)
ret
and I'm pretty damn sure that that should be totally sufficient for a
spinning rwlock. The non-spinning one is more complex just because the
unlock paths need to guarantee that something gets woken up, that just
isn't an issue when you do spinlocks.
Now, in the slow-path:
- on the rwlock slowpath side, set bit#1 to make sure that readers get
caught in the slowpath
- then do a *separate* count of how many pending readers and writers
(ie the ones that got caught into the slowpath) you have (one word
each is probably fine), and then the slowpaths can just do the right
thing depending on whether there are pending readers/writers.
See? The main lock needs not worry about number of writers AT ALL, because
it's totally irrelevant. So don't worry about running out of bits. You
won't. Just put those counts somewhere else! The only thing that matters
for the main lock word is whether there are active readers (30 bits), and
whether there is an active writer (there can only ever be one: 1 bit), and
whether new readers should be trapped (1 bit).
If you worry about overflows, you're doing something wrong.
Linus
next prev parent reply other threads:[~2008-08-21 21:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-16 7:39 [PATCH] x86_64 : support atomic ops with 64 bits integer values Mathieu Desnoyers
2008-08-16 15:04 ` H. Peter Anvin
2008-08-16 15:43 ` Mathieu Desnoyers
2008-08-16 17:30 ` Linus Torvalds
2008-08-16 21:19 ` [RFC PATCH] Fair rwlock Mathieu Desnoyers
2008-08-16 21:33 ` Linus Torvalds
2008-08-17 7:53 ` [RFC PATCH] Fair low-latency rwlock v3 Mathieu Desnoyers
2008-08-17 16:17 ` Linus Torvalds
2008-08-17 19:10 ` [RFC PATCH] Fair low-latency rwlock v5 Mathieu Desnoyers
2008-08-17 21:30 ` [RFC PATCH] Fair low-latency rwlock v5 (updated benchmarks) Mathieu Desnoyers
2008-08-18 18:59 ` [RFC PATCH] Fair low-latency rwlock v5 Linus Torvalds
2008-08-18 23:25 ` Paul E. McKenney
2008-08-19 6:04 ` Mathieu Desnoyers
2008-08-19 7:33 ` Mathieu Desnoyers
2008-08-19 9:06 ` Mathieu Desnoyers
2008-08-19 16:48 ` Linus Torvalds
2008-08-21 20:50 ` [RFC PATCH] Writer-biased low-latency rwlock v8 Mathieu Desnoyers
2008-08-21 21:00 ` Linus Torvalds
2008-08-21 21:15 ` Linus Torvalds [this message]
2008-08-21 22:22 ` Linus Torvalds
2008-08-23 5:09 ` Mathieu Desnoyers
2008-08-23 18:02 ` Linus Torvalds
2008-08-23 20:30 ` Mathieu Desnoyers
2008-08-23 21:40 ` Linus Torvalds
2008-08-21 21:26 ` H. Peter Anvin
2008-08-21 21:41 ` Linus Torvalds
2008-08-25 19:20 ` [RFC PATCH] Fair low-latency rwlock v5 Peter Zijlstra
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=alpine.LFD.1.10.0808211402370.3487@nehalem.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.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
Powered by JetHome