From: Peter Zijlstra <peterz@infradead.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Nicholas Piggin <npiggin@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>,
Will Deacon <will.deacon@arm.com>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Arnd Bergmann <arnd@arndb.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Rich Felker <dalias@libc.org>,
David Howells <dhowells@redhat.com>,
Daniel Lustig <dlustig@nvidia.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
Ingo Molnar <mingo@kernel.org>,
Palmer Dabbelt <palmer@sifive.com>,
Paul Burton <paul.burton@mips.com>,
"Paul E. McKenney" <paulmck@linux.ibm.com>,
Alan Stern <stern@rowland.harvard.edu>,
Tony Luck <tony.luck@intel.com>,
Yoshinori Sato <ysato@users.sour>
Subject: Re: [PATCH 01/20] asm-generic/mmiowb: Add generic implementation of mmiowb() tracking
Date: Thu, 7 Mar 2019 10:13:18 +0100 [thread overview]
Message-ID: <20190307091318.GA32477@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <87k1hbv7ba.fsf@concordia.ellerman.id.au>
On Thu, Mar 07, 2019 at 11:47:53AM +1100, Michael Ellerman wrote:
> The mutex unlock fast path is just:
>
> if (atomic_long_cmpxchg_release(&lock->owner, curr, 0UL) == curr)
> return true;
>
> And because it's the "release" variant we just use lwsync, which doesn't
> order MMIO. If it was just atomic_long_cmpxchg() that would work because
> we use sync for those.
>
> __up_write() uses atomic_long_sub_return_release(), so same story.
As does spin_unlock() of course, which is a great segway into...
my RCsc desires :-)
If all your unlocks were to have SYNC, your locks would, aside from
ordering MMIO, also be RCsc, Win-Win :-)
There is, of course, that pesky little performance detail that keeps
getting in the way.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Nicholas Piggin <npiggin@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>,
Will Deacon <will.deacon@arm.com>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Arnd Bergmann <arnd@arndb.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Rich Felker <dalias@libc.org>,
David Howells <dhowells@redhat.com>,
Daniel Lustig <dlustig@nvidia.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
Ingo Molnar <mingo@kernel.org>,
Palmer Dabbelt <palmer@sifive.com>,
Paul Burton <paul.burton@mips.com>,
"Paul E. McKenney" <paulmck@linux.ibm.com>,
Alan Stern <stern@rowland.harvard.edu>,
Tony Luck <tony.luck@intel.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>
Subject: Re: [PATCH 01/20] asm-generic/mmiowb: Add generic implementation of mmiowb() tracking
Date: Thu, 7 Mar 2019 10:13:18 +0100 [thread overview]
Message-ID: <20190307091318.GA32477@hirez.programming.kicks-ass.net> (raw)
Message-ID: <20190307091318.BnTesp7HlyWrUZ1_Xf9xSybigYrJtX-TaVqjSPWV3fc@z> (raw)
In-Reply-To: <87k1hbv7ba.fsf@concordia.ellerman.id.au>
On Thu, Mar 07, 2019 at 11:47:53AM +1100, Michael Ellerman wrote:
> The mutex unlock fast path is just:
>
> if (atomic_long_cmpxchg_release(&lock->owner, curr, 0UL) == curr)
> return true;
>
> And because it's the "release" variant we just use lwsync, which doesn't
> order MMIO. If it was just atomic_long_cmpxchg() that would work because
> we use sync for those.
>
> __up_write() uses atomic_long_sub_return_release(), so same story.
As does spin_unlock() of course, which is a great segway into...
my RCsc desires :-)
If all your unlocks were to have SYNC, your locks would, aside from
ordering MMIO, also be RCsc, Win-Win :-)
There is, of course, that pesky little performance detail that keeps
getting in the way.
next prev parent reply other threads:[~2019-03-07 9:13 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 14:03 [PATCH 00/20] Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb()) Will Deacon
2019-03-01 14:03 ` [PATCH 01/20] asm-generic/mmiowb: Add generic implementation of mmiowb() tracking Will Deacon
2019-03-03 1:43 ` Nicholas Piggin
2019-03-03 2:18 ` Linus Torvalds
2019-03-03 2:18 ` Linus Torvalds
2019-03-03 3:34 ` Nicholas Piggin
2019-03-03 3:34 ` Nicholas Piggin
[not found] ` <CAHk-=whVN58nWh29jvXx+X-Yx9dCC6BeAZOtKak+d01y_UVg=A@mail.gmail.com>
2019-03-03 10:05 ` Nicholas Piggin
2019-03-03 10:05 ` Nicholas Piggin
2019-03-03 18:48 ` Linus Torvalds
2019-03-03 18:48 ` Linus Torvalds
2019-03-05 0:21 ` Nicholas Piggin
2019-03-05 0:21 ` Nicholas Piggin
2019-03-05 0:33 ` Linus Torvalds
2019-03-05 0:33 ` Linus Torvalds
2019-03-03 9:26 ` Michael Ellerman
2019-03-03 10:07 ` Nicholas Piggin
2019-03-04 1:01 ` Michael Ellerman
2019-03-05 0:21 ` Nicholas Piggin
2019-03-04 10:24 ` Michael Ellerman
2019-03-05 0:19 ` Linus Torvalds
2019-03-05 0:19 ` Linus Torvalds
2019-03-07 0:47 ` Michael Ellerman
2019-03-07 0:47 ` Michael Ellerman
2019-03-07 1:13 ` Linus Torvalds
2019-03-07 1:13 ` Linus Torvalds
2019-03-07 9:13 ` Peter Zijlstra [this message]
2019-03-07 9:13 ` Peter Zijlstra
2019-03-01 14:03 ` [PATCH 02/20] arch: Use asm-generic header for asm/mmiowb.h Will Deacon
2019-03-01 14:03 ` Will Deacon
2019-03-01 14:03 ` [PATCH 03/20] mmiowb: Hook up mmiowb helpers to spinlocks and generic I/O accessors Will Deacon
2019-03-03 1:47 ` Nicholas Piggin
2019-03-01 14:03 ` [PATCH 04/20] ARM/io: Remove useless definition of mmiowb() Will Deacon
2019-03-01 14:03 ` [PATCH 05/20] arm64/io: " Will Deacon
2019-03-01 14:03 ` [PATCH 06/20] x86/io: " Will Deacon
2019-03-01 14:03 ` [PATCH 07/20] nds32/io: " Will Deacon
2019-03-01 14:03 ` [PATCH 08/20] m68k/io: " Will Deacon
2019-03-01 14:03 ` [PATCH 09/20] sh/mmiowb: Add unconditional mmiowb() to arch_spin_unlock() Will Deacon
2019-03-01 14:03 ` [PATCH 10/20] mips/mmiowb: " Will Deacon
2019-03-01 22:16 ` Paul Burton
2019-03-01 14:03 ` [PATCH 11/20] ia64/mmiowb: " Will Deacon
2019-03-01 14:03 ` [PATCH 12/20] powerpc/mmiowb: Hook up mmwiob() implementation to asm-generic code Will Deacon
2019-03-02 12:46 ` Michael Ellerman
2019-03-02 12:46 ` Michael Ellerman
2019-03-02 12:46 ` Michael Ellerman
2019-03-01 14:03 ` [PATCH 13/20] riscv/mmiowb: " Will Deacon
2019-03-01 21:13 ` Palmer Dabbelt
2019-03-01 21:13 ` Palmer Dabbelt
2019-03-01 14:03 ` [PATCH 14/20] Documentation: Kill all references to mmiowb() Will Deacon
2019-03-01 14:03 ` [PATCH 15/20] drivers: Remove useless trailing comments from mmiowb() invocations Will Deacon
2019-03-01 14:03 ` [PATCH 16/20] drivers: Remove explicit invocations of mmiowb() Will Deacon
2019-03-01 14:03 ` [PATCH 17/20] scsi/qla1280: Remove stale comment about mmiowb() Will Deacon
2019-03-01 14:03 ` [PATCH 18/20] i40iw: Redefine i40iw_mmiowb() to do nothing Will Deacon
2019-03-01 14:03 ` [PATCH 19/20] net/ethernet/silan/sc92031: Remove stale comment about mmiowb() Will Deacon
2019-03-01 14:03 ` [PATCH 20/20] arch: Remove dummy mmiowb() definitions from arch code Will Deacon
2019-03-01 16:41 ` [PATCH 00/20] Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb()) Linus Torvalds
2019-03-02 12:56 ` Michael Ellerman
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=20190307091318.GA32477@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrea.parri@amarulasolutions.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=dalias@libc.org \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=palmer@sifive.com \
--cc=paul.burton@mips.com \
--cc=paulmck@linux.ibm.com \
--cc=stern@rowland.harvard.edu \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=ysato@users.sour \
/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.