From: George Guo <dongtai.guo@linux.dev>
To: Hengqi Chen <hengqi.chen@gmail.com>
Cc: Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
George Guo <guodongtai@kylinos.cn>
Subject: Re: [PATCH v3 0/2] LoongArch: Add 128-bit atomic cmpxchg support (v3)
Date: Wed, 26 Nov 2025 17:40:16 +0800 [thread overview]
Message-ID: <20251126174016.000067f4@linux.dev> (raw)
In-Reply-To: <CAEyhmHTJU-OUZFA5Sdiv+mBwQpfq5CZp5kN9HVKRqbQzqRS66Q@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB18030, Size: 3858 bytes --]
On Wed, 26 Nov 2025 13:23:57 +0800
Hengqi Chen <hengqi.chen@gmail.com> wrote:
> On Wed, Nov 26, 2025 at 10:066§2AM George Guo <dongtai.guo@linux.dev>
> wrote:
> >
> > This patch series adds 128-bit atomic compare-and-exchange support
> > for LoongArch architecture, which fixes BPF scheduler test failures
> > caused by missing 128-bit atomics support.
> >
> > The series consists of two patches:
> >
> > 1. "LoongArch: Add 128-bit atomic cmpxchg support"
> > - Implements 128-bit atomic compare-and-exchange using
> > LoongArch's LL.D/SC.Q instructions
> > - Fixes BPF scheduler test failures (scx_central scx_qmap) where
> > kmalloc_nolock_noprof returns NULL due to missing 128-bit
> > atomics, leading to -ENOMEM errors during scheduler initialization
> >
>
> This kmalloc_nolock_noprof() was introduced in v6.18-rc1 and has no
> caller for now.
> Why is this related to the sched_ext failure ?
>
Hi Hengqi,
When running scx_central, function call chain as below:
central_init->bpf_timer_init->__bpf_async_init->bpf_map_kmalloc_nolock->kmalloc_nolock
->kmalloc_nolock_noprof
The function kmalloc_nolock_noprof returns NULL due to the following
condition:
if (!(s->flags & __CMPXCHG_DOUBLE) && !kmem_cache_debug(s))
/*
* kmalloc_nolock() is not supported on architectures that
* don't implement cmpxchg16b, but debug caches don't use
* per-cpu slab and per-cpu partial slabs. They rely on
* kmem_cache_node->list_lock, so kmalloc_nolock() can
* attempt to allocate from debug caches by
* spin_trylock_irqsave(&n->list_lock, ...)
*/
return NULL;
The NULL return occurs because kmalloc_nolock is not supported on
Loongarch, which don't implement cmpxchg16b. So I am giving the patch.
Also I tried with debug caches(CONFIG_SLUB_DEBUG_ON=y), it works,
but not a good idea.
> > 2. "LoongArch: Enable 128-bit atomics cmpxchg support"
> > - Adds select HAVE_CMPXCHG_DOUBLE and select
> > HAVE_ALIGNED_STRUCT_PAGE in Kconfig to enable 128-bit atomic
> > cmpxchg support
> >
> > The issue was identified through BPF scheduler test failures where
> > scx_central and scx_qmap schedulers would fail to initialize.
> > Testing was performed using the scx_qmap scheduler from
> > tools/sched_ext/, confirming that the patches resolve the
> > initialization failures.
> >
> > Signed-off-by: George Guo <dongtai.guo@linux.dev>
> > ---
> > Changes in v3:
> > - dbar 0 -> __WEAK_LLSC_MB
> > - =ZB" (__ptr[0]) -> "r" (__ptr)
> > - Link to v2:
> > https://lore.kernel.org/r/20251124-2-v2-0-b38216e25fd9@linux.dev
> >
> > Changes in v2:
> > - Use a normal ld.d for the high word instead of ll.d to avoid race
> > condition
> > - Insert a dbar between ll.d and ld.d to prevent reordering
> > - Simply __cmpxchg128_asm("ll.d", "sc.q", ptr, o, n) to
> > __cmpxchg128_asm(ptr, o, n)
> > - Fix address operand constraints after testing different
> > approaches:
> > * ld.d with "m"
> > * ll.d with "ZC",
> > * sc.q with "ZB"(alternative constraints caused issues:
> > - "r" caused system hang
> > - "ZC" caused compiler error:
> > {standard input}: Assembler messages:
> > {standard input}:10037: Fatal error: Immediate overflow.
> > format: u0:0 )
> > - Link to v1:
> > https://lore.kernel.org/r/20251120-2-v1-0-705bdc440550@linux.dev
> >
> > ---
> > George Guo (2):
> > LoongArch: Add 128-bit atomic cmpxchg support
> > LoongArch: Enable 128-bit atomics cmpxchg support
> >
> > arch/loongarch/Kconfig | 2 ++
> > arch/loongarch/include/asm/cmpxchg.h | 47
> > ++++++++++++++++++++++++++++++++++++ 2 files changed, 49
> > insertions(+) ---
> > base-commit: d5ae5ac32615e4af729f0610fdc11ff4f4798aef
> > change-id: 20251120-2-d03862b2cf6d
> >
> > Best regards,
> > --
> > George Guo <dongtai.guo@linux.dev>
> >
> >
next prev parent reply other threads:[~2025-11-26 9:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 2:05 [PATCH v3 0/2] LoongArch: Add 128-bit atomic cmpxchg support (v3) George Guo
2025-11-26 2:05 ` [PATCH v3 1/2] LoongArch: Add 128-bit atomic cmpxchg support George Guo
2025-11-26 2:05 ` [PATCH v3 2/2] LoongArch: Enable 128-bit atomics " George Guo
2025-11-26 4:44 ` [PATCH v3 0/2] LoongArch: Add 128-bit atomic cmpxchg support (v3) Huacai Chen
2025-11-26 9:42 ` George Guo
2025-11-26 5:23 ` Hengqi Chen
2025-11-26 9:40 ` George Guo [this message]
2025-11-26 11:05 ` Hengqi Chen
2025-11-27 4:15 ` Hengqi Chen
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=20251126174016.000067f4@linux.dev \
--to=dongtai.guo@linux.dev \
--cc=chenhuacai@kernel.org \
--cc=guodongtai@kylinos.cn \
--cc=hengqi.chen@gmail.com \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
/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