linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: linux-arch@vger.kernel.org, Will Deacon <will.deacon@arm.com>
Cc: 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-kernel@vger.kernel.org,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Ingo Molnar <mingo@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Palmer Dabbelt <palmer@sifive.com>,
	Paul Burton <paul.burton@mips.com>,
	"Paul E. McKenney" <paulmck@linux.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Tony Luck <tony.luck@intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>
Subject: Re: [PATCH 01/20] asm-generic/mmiowb: Add generic implementation of mmiowb() tracking
Date: Sun, 03 Mar 2019 11:43:09 +1000	[thread overview]
Message-ID: <1551575210.6lwpiqtg5k.astroid@bobo.none> (raw)
In-Reply-To: <20190301140348.25175-2-will.deacon@arm.com>

Will Deacon's on March 2, 2019 12:03 am:
> In preparation for removing all explicit mmiowb() calls from driver
> code, implement a tracking system in asm-generic based loosely on the
> PowerPC implementation. This allows architectures with a non-empty
> mmiowb() definition to have the barrier automatically inserted in
> spin_unlock() following a critical section containing an I/O write.

Is there a reason to call this "mmiowb"? We already have wmb that
orders cacheable stores vs mmio stores don't we?

Yes ia64 "sn2" is broken in that case, but that can be fixed (if
anyone really cares about the platform any more). Maybe that's
orthogonal to what you're doing here, I just don't like seeing
"mmiowb" spread.

This series works for spin locks, but you would want a driver to
be able to use wmb() to order locks vs mmio when using a bit lock
or a mutex or whatever else. Calling your wmb-if-io-is-pending
version io_mb_before_unlock() would kind of match with existing
patterns.

> +static inline void mmiowb_set_pending(void)
> +{
> +	struct mmiowb_state *ms = __mmiowb_state();
> +	ms->mmiowb_pending = ms->nesting_count;
> +}
> +
> +static inline void mmiowb_spin_lock(void)
> +{
> +	struct mmiowb_state *ms = __mmiowb_state();
> +	ms->nesting_count++;
> +}
> +
> +static inline void mmiowb_spin_unlock(void)
> +{
> +	struct mmiowb_state *ms = __mmiowb_state();
> +
> +	if (unlikely(ms->mmiowb_pending)) {
> +		ms->mmiowb_pending = 0;
> +		mmiowb();
> +	}
> +
> +	ms->nesting_count--;
> +}

Humour me for a minute and tell me what this algorithm is doing, or
what was broken about the powerpc one, which is basically:

static inline void mmiowb_set_pending(void)
{
	struct mmiowb_state *ms = __mmiowb_state();
	ms->mmiowb_pending = 1;
}

static inline void mmiowb_spin_lock(void)
{
}

static inline void mmiowb_spin_unlock(void)
{
	struct mmiowb_state *ms = __mmiowb_state();

	if (unlikely(ms->mmiowb_pending)) {
		ms->mmiowb_pending = 0;
		mmiowb();
	}
}

> diff --git a/include/asm-generic/mmiowb_types.h b/include/asm-generic/mmiowb_types.h
> new file mode 100644
> index 000000000000..8eb0095655e7
> --- /dev/null
> +++ b/include/asm-generic/mmiowb_types.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_GENERIC_MMIOWB_TYPES_H
> +#define __ASM_GENERIC_MMIOWB_TYPES_H
> +
> +#include <linux/types.h>
> +
> +struct mmiowb_state {
> +	u16	nesting_count;
> +	u16	mmiowb_pending;
> +};

Really need more than 255 nested spin locks? I had the idea that 16
bit operations were a bit more costly than 8 bit on some CPUs... may
not be true, but at least the smaller size packs a bit better on
powerpc.

Thanks,
Nick


  reply	other threads:[~2019-03-03  1:43 UTC|newest]

Thread overview: 43+ 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 [this message]
2019-03-03  2:18     ` Linus Torvalds
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 18:48             ` Linus Torvalds
2019-03-05  0:21               ` Nicholas Piggin
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-07  0:47         ` Michael Ellerman
2019-03-07  1:13           ` Linus Torvalds
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 ` [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-01 14:03 ` [PATCH 13/20] riscv/mmiowb: " Will Deacon
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=1551575210.6lwpiqtg5k.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --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=palmer@sifive.com \
    --cc=paul.burton@mips.com \
    --cc=paulmck@linux.ibm.com \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    --cc=ysato@users.sourceforge.jp \
    /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;
as well as URLs for NNTP newsgroup(s).