From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: "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>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] Fair low-latency rwlock v5
Date: Mon, 18 Aug 2008 11:59:32 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0808181150420.3324@nehalem.linux-foundation.org> (raw)
In-Reply-To: <20080817191034.GA5258@Krystal>
On Sun, 17 Aug 2008, Mathieu Desnoyers wrote:
>
> Ah, you are right. This new version implements a "single cmpxchg"
> uncontended code path, changes the _fast semantic for "trylock
> uncontended" and also adds the trylock primitives.
Can you also finally
- separate out the fastpaths more clearly. The slowpaths should not be
even visible in the I$ footprint. The fastpaths are probably better off
as a separate "fastpath.S" file to make sure that the compiler doesn't
inline the slowpath or do other insane things.
If the fastpath isn't just a few instructions, there's something wrong.
It should be written in assembly, so that it's very clear what the
fastpath is. Because most of the time, the fastpath is all that really
matters (at least as long as there is some reasonable slow-path and
contention behaviour - the slowpath matters int hat it shouldn't ever
be a _problem_).
- don't call these "fair". They may be fairER than the regular rwlocks,
but you'd really need to explain that, and true fairness you (a) can't
really get without explicit queueing and (b) probably don't even want,
because the only starvation people tend to worry about is reader vs
writer, and writer-writer fairness tends to be unimportant. So it's not
that people want the (expensive) "fairness" it's really that they want
something _reasonably_ fair considering the normal worries.
(ie if you have so much write activity that you get into write-write
fairness worries, you shouldn't be using a rwlock to begin with, so
that level of fairness is simply not very interesting).
People react emotionally and too strongly to to words like "fairness"
or "freedom". Different people have different ideas on what they mean,
and take them to pointless extremes. So just don't use the words, they
just detract from the real issue.
Also, the performance numbers on their own are pretty irrelevant, since
there's nothing to compare them to. It would be much more relevant if you
had a "this is what the standard rwlock" does as a comparison for each
number.
Linus
next prev parent reply other threads:[~2008-08-18 19:03 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 ` Linus Torvalds [this message]
2008-08-18 23:25 ` [RFC PATCH] Fair low-latency rwlock v5 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
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.0808181150420.3324@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 \
/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®