linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Huacai Chen <chenhuacai@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>, Guo Ren <guoren@kernel.org>,
	Waiman Long <llong@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Huacai Chen <chenhuacai@loongson.cn>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	Rui Wang <wangrui@loongson.cn>,
	Xuefeng Li <lixuefeng@loongson.cn>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>
Subject: Re: [PATCH RFC 1/2] arch: Introduce ARCH_HAS_HW_XCHG_SMALL
Date: Wed, 28 Jul 2021 18:40:54 +0800	[thread overview]
Message-ID: <CAAhV-H7Jnoa3AOTjG_=+WvxkcjqDxYVU4jAudjnu8WMtAVyPCw@mail.gmail.com> (raw)
In-Reply-To: <YP/oYc1A39bMS87H@hirez.programming.kicks-ass.net>

Hi, Peter,

On Tue, Jul 27, 2021 at 7:06 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Jul 27, 2021 at 10:29:59AM +0800, Boqun Feng wrote:
>
> > > "How to implement xchg_tail" shouldn't force with _Q_PENDING_BITS, but
> > > the arch could choose.
> >
> > I actually agree with this part, but this patchset failed to provide
> > enough evidences on why we should choose xchg_tail() implementation
> > based on whether hardware has xchg16, more precisely, for an archtecture
> > which doesn't have a hardware xchg16, why cmpxchg emulated xchg16() is
> > worse than a "load+cmpxchg) implemeneted xchg_tail()? If it's a
> > performance reason, please show some numbers.
>
> Right. Their problem is their broken xchg16() implementation.

Please correct me if I'm wrong. Now my understanding is like this:
1, _Q_PENDING_BITS=1 qspinlock can be used by all archs, though it may
be not optimized.
2, _Q_PENDING_BITS=8 qspinlock can be used if hardware supports
sub-word xchg/cmpxchg, or the software emulation is correctly
implemented. But the current MIPS emulation is not correct.

If so, I want to rename ARCH_HAS_HW_XCHG_SMALL to
ARCH_HAS_FAST_XCHG_SMALL, and let these archs select it:
1, X86, ARM, ARM64, IA64, M68K, because they have hardware support.
2, Other archs who select qspinlock currently (including MIPS),
because their current behavior is use _Q_PENDING_BITS=8 qspinlock and
we don't want to change anything in this patch. If their emulation is
broken or not as "fast" as expected, we can make new patches to
unselect the ARCH_HAS_FAST_XCHG_SMALL option.

Huacai

  reply	other threads:[~2021-07-28 10:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-24 12:36 [PATCH RFC 1/2] arch: Introduce ARCH_HAS_HW_XCHG_SMALL Huacai Chen
2021-07-24 12:36 ` [PATCH RFC 2/2] qspinlock: Use ARCH_HAS_HW_XCHG_SMALL to select _Q_PENDING_BITS definition Huacai Chen
2021-07-24 19:24 ` [PATCH RFC 1/2] arch: Introduce ARCH_HAS_HW_XCHG_SMALL Arnd Bergmann
2021-07-25  3:06   ` Jiaxun Yang
2021-07-25 10:08     ` Arnd Bergmann
2021-07-26  8:36 ` Geert Uytterhoeven
2021-07-26  8:56   ` Huacai Chen
2021-07-26 10:39     ` Boqun Feng
2021-07-26 16:41       ` Guo Ren
2021-07-26 17:03         ` Boqun Feng
2021-07-26 21:20           ` Waiman Long
2021-07-27  1:27             ` Guo Ren
2021-07-27  2:29               ` Boqun Feng
2021-07-27  2:46                 ` Waiman Long
2021-07-27 11:05                 ` Peter Zijlstra
2021-07-28 10:40                   ` Huacai Chen [this message]
2021-07-28 11:01                     ` Peter Zijlstra
2021-07-29 16:38                       ` Huacai Chen
2021-07-27 10:17             ` Peter Zijlstra
2021-07-27  1:07           ` Guo Ren
2021-07-27  1:52             ` Wang Rui
2021-07-27 11:03               ` Peter Zijlstra
2021-07-27  2:00             ` Boqun Feng
2021-07-27 10:50             ` Peter Zijlstra
2021-07-27 10:12           ` Peter Zijlstra
2021-07-26  9:00   ` Arnd Bergmann

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='CAAhV-H7Jnoa3AOTjG_=+WvxkcjqDxYVU4jAudjnu8WMtAVyPCw@mail.gmail.com' \
    --to=chenhuacai@gmail.com \
    --cc=arnd@arndb.de \
    --cc=boqun.feng@gmail.com \
    --cc=chenhuacai@loongson.cn \
    --cc=geert@linux-m68k.org \
    --cc=guoren@kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=lixuefeng@loongson.cn \
    --cc=llong@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=wangrui@loongson.cn \
    --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 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).