From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: "wuqiang.matt" <wuqiang.matt@bytedance.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>, Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Andi Shyti <andi.shyti@linux.intel.com>,
Palmer Dabbelt <palmer@rivosinc.com>,
Andrzej Hajda <andrzej.hajda@intel.com>,
linux-trace-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
mattwu@163.com
Subject: Re: [PATCH 3/3] locking/atomic: openrisc: use generic_cmpxchg[64]_local for arch_cmpxchg[64]_local
Date: Sat, 28 Oct 2023 21:49:18 +0900 [thread overview]
Message-ID: <20231028214918.e32265f1dd2ef26fd9d2d1c2@kernel.org> (raw)
In-Reply-To: <66f5645c-f9f5-4c53-9503-a1f8470a9bee@bytedance.com>
Hi Wuqiang,
On Thu, 26 Oct 2023 19:05:51 +0800
"wuqiang.matt" <wuqiang.matt@bytedance.com> wrote:
> On 2023/10/26 16:46, Arnd Bergmann wrote:
> > On Thu, Oct 26, 2023, at 09:39, wuqiang.matt wrote:
> >> arch_cmpxchg[64]_local() are not defined for openrisc. So implement
> >> them with generci_cmpxchg[64]_local, advised by Masami Hiramatsu.
> >>
> >> Closes:
> >> https://lore.kernel.org/linux-trace-kernel/169824660459.24340.14614817132696360531.stgit@devnote2
> >> Closes:
> >> https://lore.kernel.org/oe-kbuild-all/202310241310.Ir5uukOG-lkp@intel.com
> >>
> >> Signed-off-by: wuqiang.matt <wuqiang.matt@bytedance.com>
> >
> > I think on architectures that have actual atomics, you
> > generally want to define this to be the same as arch_cmpxchg()
> > rather than the generic version.
> >
> > It depends on the relative cost of doing one atomic compared
> > to an irq-disable/enable pair, but everyone else went with
> > the former if they could. The exceptions are armv4/armv5,
> > sparc32 and parisc, which don't have a generic cmpxchg()
> > or similar operation.
>
> Sure, better native than the generic. I'll try to collect more
> insights before next move.
So I will temporally remove the last change (use arch_cmpxchg_local
in objpool) until these series are rewritten with arch native code,
so that the next release will not break the kernel build.
But this must be fixed because arch_cmpxchg_local() is required
for each arch anyway.
>
> > You could do the thing that sparc64 and xtensa do, which
> > use the native cmpxchg for supported word sizes but the
> > generic version for 1- and 2-byte swaps, but that has its
> > own set of problems if you end up doing operations on both
> > the entire word and a sub-unit of the same thing.
>
> Thank you for pointing out this. I'll do some research on these
> implementations.
arc also has the LL-SC instruction but depends on the core feature,
so I think we can use it.
Thank you,
>
> > Arnd
>
> Regards,
> wuqiang
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2023-10-28 12:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 7:39 [PATCH 3/3] locking/atomic: openrisc: use generic_cmpxchg[64]_local for arch_cmpxchg[64]_local wuqiang.matt
2023-10-26 8:46 ` Arnd Bergmann
2023-10-26 11:05 ` wuqiang.matt
2023-10-28 12:49 ` Masami Hiramatsu [this message]
2023-10-28 16:40 ` wuqiang.matt
2023-10-28 16:40 ` wuqiang.matt
2023-10-29 3:26 ` Masami Hiramatsu
2023-10-29 3:26 ` Masami Hiramatsu
2023-10-30 2:22 ` Vineet Gupta
2023-10-30 2:22 ` Vineet Gupta
2023-10-30 3:41 ` wuqiang.matt
2023-10-30 3:41 ` wuqiang.matt
2023-11-02 4:53 ` Vineet Gupta
2023-11-02 4:53 ` Vineet Gupta
2023-11-02 9:30 ` wuqiang.matt
2023-11-02 9:30 ` wuqiang.matt
2023-11-02 10:05 ` wuqiang.matt
2023-11-02 10:05 ` wuqiang.matt
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=20231028214918.e32265f1dd2ef26fd9d2d1c2@kernel.org \
--to=mhiramat@kernel.org \
--cc=andi.shyti@linux.intel.com \
--cc=andrzej.hajda@intel.com \
--cc=arnd@arndb.de \
--cc=jonas@southpole.se \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mattwu@163.com \
--cc=mingo@kernel.org \
--cc=palmer@rivosinc.com \
--cc=peterz@infradead.org \
--cc=shorne@gmail.com \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=wuqiang.matt@bytedance.com \
/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.