All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: Paul Burton <paul.burton@imgtec.com>,
	linux-mips@vger.kernel.org,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Will Deacon <will@kernel.org>, Boqun Feng <boqun.feng@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6] MIPS: Octeon: qspinlock: Flush write buffer
Date: Thu, 28 Jan 2021 16:26:00 +0100	[thread overview]
Message-ID: <YBLXiG3UxLNDB5xK@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <f8344f35-cdf1-ec3d-dcd0-7bfc392ef6e0@nokia.com>

On Thu, Jan 28, 2021 at 01:13:03PM +0100, Alexander Sverdlin wrote:
> Hi!
> 
> On 28/01/2021 12:35, Peter Zijlstra wrote:
> >> My point was that original MIPS spinlocks had this write-buffer-flush and
> >> it got lost on the conversion to qspinlocks. The referenced commit just
> >> allows to see the last MIPS-specific implementation before deletion.
> > Hardware that needs a store-buffer flush after release is highly suspect
> > and needs big and explicit comments. Not vague hints.
> 
> I have a feeling that you are not going to suggest the comments for the code
> and one has to guess what is it you have in mind?

I've no insight in the specific microarch that causes this weirdness, so
it's very hard for me to suggest something here.

Find inspiration in the loongson commit.

> Do you think the proper approach would be to undelete MIPS spinlocks and
> make these broken qspinlocks a configurable option for MIPS? I don't even
> mind if they will be default option for those not interested in performance
> or latency.

qspinlock really isn't the only generic code that relies on this. I
would seriously consider doing the loongson-v3 thing, possibly also
adding that nudge_writes() thing to your smp_store_release(), you
already have it in __clear_bit_unlock().

It would then look something like:


/*
 * Octeon is special; it does not do read speculation, therefore an
 * smp_wmb() is sufficient to generate {load,store}->{store} order
 * required for RELEASE. It however has store-buffer weirdness
 * that requires an additional smp_wmb() (which is a completion barrier
 * for them) to flush the store-buffer, otherwise visibility of the
 * store can be arbitrarily delayed, also see __SYNC_loongson3_war.
 */
#define __smp_store_release(p, v) \
do { \
	compiletime_assert_atomic_type(*p); \
	__smp_wmb(); \
	WRITE_ONCE(*p, v); \
	__smp_wmb(); \
} while (0)

/*
 * Octeon also likes to retain stores, see __SYNC_loongson3_war.
 */
#define cpu_relax()	__smp_wmb();


Or something...

  reply	other threads:[~2021-01-28 15:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 20:36 [PATCH 0/6] MIPS: qspinlock: Try to reduce reduce the spinlock regression Alexander A Sverdlin
2021-01-27 20:36 ` [PATCH 1/6] MIPS: Octeon: Implement __smp_store_release() Alexander A Sverdlin
2021-01-27 22:32   ` Peter Zijlstra
2021-01-28  7:27     ` Alexander Sverdlin
2021-01-28 11:33       ` Peter Zijlstra
2021-01-28 11:52         ` Alexander Sverdlin
2021-01-28 14:57           ` Peter Zijlstra
2021-01-28 15:15             ` Peter Zijlstra
2021-01-28 12:09         ` Alexander Sverdlin
2021-01-28 15:04           ` Peter Zijlstra
2021-01-27 20:36 ` [PATCH 2/6] MIPS: Implement atomic_cmpxchg_relaxed() Alexander A Sverdlin
2021-01-27 20:36 ` [PATCH 3/6] MIPS: Octeon: qspinlock: Flush write buffer Alexander A Sverdlin
2021-01-27 22:34   ` Peter Zijlstra
2021-01-28  7:29     ` Alexander Sverdlin
2021-01-28 11:35       ` Peter Zijlstra
2021-01-28 12:13         ` Alexander Sverdlin
2021-01-28 15:26           ` Peter Zijlstra [this message]
2021-01-27 20:36 ` [PATCH 4/6] MIPS: Octeon: qspinlock: Exclude mmiowb() Alexander A Sverdlin
2021-01-27 22:35   ` Peter Zijlstra
2021-01-27 20:36 ` [PATCH 5/6] MIPS: Provide {atomic_}xchg_relaxed() Alexander A Sverdlin
2021-01-27 20:36 ` [PATCH 6/6] MIPS: cmpxchg: Use cmpxchg_local() for {cmp_}xchg_small() Alexander A Sverdlin
2021-01-27 22:37   ` Peter Zijlstra

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=YBLXiG3UxLNDB5xK@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=alexander.sverdlin@nokia.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paul.burton@imgtec.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=will@kernel.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.