From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Nick Piggin <npiggin@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: queued spinlock code and results
Date: Sun, 8 Jul 2007 09:49:58 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0707080942170.31544@woody.linux-foundation.org> (raw)
In-Reply-To: <p733azz16vh.fsf@bingen.suse.de>
On Sun, 8 Jul 2007, Andi Kleen wrote:
>
> Nick Piggin <npiggin@suse.de> writes:
>
> > I made some tests of the queued spinlock code using userspace test code on
> > 64-bit processors. I believe the xadd based code no longer has any theoretical
> > memory ordering problems.
>
> Linus, the background of this is that on 8 socket Opteron systems
> the current spinlocks can become very unfair to the point of severe
> starvation. These boxes are becomming more common.
Yeah, considering the numbers, I don't have any real objections here.
I would ask that the code be given to both Intel and AMD engineers to look
over, just to verify that the lfence is sufficient (or whether it's even
needed), but I think the use of "xaddw" to both increment _and_ load the
old value for the non-contention case is an obviously good (and clever)
way to handle that one, and even if we'd have to add something heavier
than the lfence to the contended case, it looks fine to me.
So the only remaining issue is that unfairness is probably really good for
some loads (not just for the spinlock itself - it will likely cause much
better cache behaviour for stuff _inside_ the lock to stay on the same
core), but I don't think we want to optimize for the contended case
anyway, so that's more of a "it will be interesting to see" kind of
comment.
In short: if we can have AMD/Intel engineers look this over for any subtle
issues, and they are happy, then I'm happy.
Linus
next prev parent reply other threads:[~2007-07-08 16:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-08 4:32 Nick Piggin
2007-07-08 11:18 ` Andi Kleen
2007-07-08 10:40 ` Nick Piggin
2007-07-08 16:49 ` Linus Torvalds [this message]
2007-07-10 20:52 ` Christoph Lameter
2007-07-11 2:06 ` Nick Piggin
2007-07-11 2:26 ` Christoph Lameter
2007-07-11 4:51 ` Nick Piggin
2007-07-09 19:01 ` Davide Libenzi
2007-07-09 19:16 ` Davide Libenzi
2007-07-09 19:26 ` Linus Torvalds
2007-07-09 19:47 ` Davide Libenzi
2007-07-09 19:55 ` Linus Torvalds
2007-07-09 20:08 ` Linus Torvalds
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.0.999.0707080942170.31544@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/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®