From: Paul Mackerras <paulus@samba.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] unify semaphore implementations
Date: Sat, 30 Apr 2005 11:45:04 +1000 [thread overview]
Message-ID: <17010.58144.95239.716600@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <1114789320.10086.81.camel@lade.trondhjem.org>
Trond Myklebust writes:
> The PPC implementation would be hard to port to x86, since it relies on
> the load-linked/store-conditional stuff to provide a fast primitive for
> atomic_dec_if_positive().
The only fast path that needs atomic_dec_if_positive is down_trylock.
You can use atomic_dec for down_trylock instead; the only downside to
that is that if somebody was holding the semaphore but nobody was
waiting, the holder will take the slow path when it does the up. Or
you can use cmpxchg for down_trylock. I believe that down_trylock is
used much less than down and down_interruptible, so it shouldn't
matter if down_trylock is a few nanoseconds slower than down.
> The only way I found to implement that on x86 was to use cmpxchg. On my
> machine, therefore, a spinlock-based semaphore implementation turns out
> to be at least as fast for the "fast" path (and is naturally much more
> efficient for the slow path).
What is "your machine"? Is a single cmpxchg really slower than
locking and unlocking a spinlock? If so, by how much?
Paul.
next prev parent reply other threads:[~2005-04-30 1:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-28 18:29 Benjamin LaHaise
2005-04-28 18:48 ` James Bottomley
2005-04-28 18:59 ` Benjamin LaHaise
2005-04-28 18:53 ` David S. Miller
2005-04-28 22:40 ` Russell King
2005-04-29 0:42 ` Trond Myklebust
2005-04-29 1:26 ` Paul Mackerras
2005-04-28 22:54 ` David Howells
2005-04-29 0:44 ` Paul Mackerras
2005-04-29 5:33 ` Richard Henderson
2005-04-29 14:14 ` Benjamin LaHaise
2005-04-29 15:42 ` Trond Myklebust
2005-04-30 1:45 ` Paul Mackerras [this message]
2005-04-30 5:13 ` Paul Mackerras
2005-04-30 16:40 ` Trond Myklebust
2005-04-30 1:49 ` Paul Mackerras
2005-04-30 16:50 ` Trond Myklebust
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=17010.58144.95239.716600@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=bcrl@kvack.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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®