From: Nick Piggin <npiggin@suse.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-arch@vger.kernel.org, linuxppc-dev@ozlabs.org,
paulus@samba.org, Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [patch] mutex: optimise generic mutex implementations
Date: Thu, 23 Oct 2008 09:02:08 +0200 [thread overview]
Message-ID: <20081023070207.GA30765@wotan.suse.de> (raw)
In-Reply-To: <1224737038.7654.385.camel@pasglop>
On Thu, Oct 23, 2008 at 03:43:58PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-22 at 17:59 +0200, Ingo Molnar wrote:
> > * Nick Piggin <npiggin@suse.de> wrote:
> >
> > > Speed up generic mutex implementations.
> > >
> > > - atomic operations which both modify the variable and return something imply
> > > full smp memory barriers before and after the memory operations involved
> > > (failing atomic_cmpxchg, atomic_add_unless, etc don't imply a barrier because
> > > they don't modify the target). See Documentation/atomic_ops.txt.
> > > So remove extra barriers and branches.
> > >
> > > - All architectures support atomic_cmpxchg. This has no relation to
> > > __HAVE_ARCH_CMPXCHG. We can just take the atomic_cmpxchg path unconditionally
> > >
> > > This reduces a simple single threaded fastpath lock+unlock test from 590 cycles
> > > to 203 cycles on a ppc970 system.
> > >
> > > Signed-off-by: Nick Piggin <npiggin@suse.de>
> >
> > no objections here. Lets merge these two patches via the ppc tree, so
> > that it gets testing on real hardware as well?
> >
> > Acked-by: Ingo Molnar <mingo@elte.hu>
>
> Allright but in that case it will be after -rc1 unless I manage to sneak
> something in tomorrow before linux closes the merge window.
>
> I can't get an update today.
Fine with me.
Thanks,
Nick
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-arch@vger.kernel.org, linuxppc-dev@ozlabs.org,
Ingo Molnar <mingo@elte.hu>,
paulus@samba.org, Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [patch] mutex: optimise generic mutex implementations
Date: Thu, 23 Oct 2008 09:02:08 +0200 [thread overview]
Message-ID: <20081023070207.GA30765@wotan.suse.de> (raw)
In-Reply-To: <1224737038.7654.385.camel@pasglop>
On Thu, Oct 23, 2008 at 03:43:58PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-22 at 17:59 +0200, Ingo Molnar wrote:
> > * Nick Piggin <npiggin@suse.de> wrote:
> >
> > > Speed up generic mutex implementations.
> > >
> > > - atomic operations which both modify the variable and return something imply
> > > full smp memory barriers before and after the memory operations involved
> > > (failing atomic_cmpxchg, atomic_add_unless, etc don't imply a barrier because
> > > they don't modify the target). See Documentation/atomic_ops.txt.
> > > So remove extra barriers and branches.
> > >
> > > - All architectures support atomic_cmpxchg. This has no relation to
> > > __HAVE_ARCH_CMPXCHG. We can just take the atomic_cmpxchg path unconditionally
> > >
> > > This reduces a simple single threaded fastpath lock+unlock test from 590 cycles
> > > to 203 cycles on a ppc970 system.
> > >
> > > Signed-off-by: Nick Piggin <npiggin@suse.de>
> >
> > no objections here. Lets merge these two patches via the ppc tree, so
> > that it gets testing on real hardware as well?
> >
> > Acked-by: Ingo Molnar <mingo@elte.hu>
>
> Allright but in that case it will be after -rc1 unless I manage to sneak
> something in tomorrow before linux closes the merge window.
>
> I can't get an update today.
Fine with me.
Thanks,
Nick
next prev parent reply other threads:[~2008-10-23 7:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 5:46 [patch] mutex: optimise generic mutex implementations Nick Piggin
2008-10-12 5:47 ` [patch] powerpc: implement optimised mutex fastpaths Nick Piggin
2008-10-13 1:18 ` Nick Piggin
2008-11-06 4:09 ` Paul Mackerras
2008-11-06 4:09 ` Paul Mackerras
2008-11-06 5:06 ` Nick Piggin
2008-11-06 5:06 ` Nick Piggin
2008-10-13 16:15 ` Scott Wood
2008-10-13 16:15 ` Scott Wood
2008-10-13 16:20 ` Scott Wood
2008-10-14 7:06 ` Nick Piggin
2008-10-14 8:35 ` [patch] mutex: optimise generic mutex implementations Benjamin Herrenschmidt
2008-10-14 8:35 ` Benjamin Herrenschmidt
2008-10-22 15:59 ` Ingo Molnar
2008-10-22 15:59 ` Ingo Molnar
2008-10-23 4:43 ` Benjamin Herrenschmidt
2008-10-23 4:43 ` Benjamin Herrenschmidt
2008-10-23 7:02 ` Nick Piggin [this message]
2008-10-23 7:02 ` Nick Piggin
2008-10-22 16:24 ` David Howells
2008-10-22 16:24 ` David Howells
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=20081023070207.GA30765@wotan.suse.de \
--to=npiggin@suse.de \
--cc=a.p.zijlstra@chello.nl \
--cc=benh@kernel.crashing.org \
--cc=linux-arch@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.