All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Walmsley <pjw@kernel.org>
To: Xie Bo <xb@ultrarisc.com>
Cc: Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	 Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	 linux-riscv@lists.infradead.org, Dennis Zhou <dennis@kernel.org>,
	 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
	 Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	 linux-mm@kvack.org, linux-doc@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: Add native this_cpu_cmpxchg() support
Date: Thu, 20 Aug 2026 19:27:16 -0600 (MDT)	[thread overview]
Message-ID: <8b8cbb4a-474d-1de4-eaf2-dd8b4e6ca8ec@kernel.org> (raw)
In-Reply-To: <20260730094407.16588-1-xb@ultrarisc.com>

Hi, 

On Thu, 30 Jul 2026, Xie Bo wrote:

> RISC-V falls back to the generic this_cpu_cmpxchg() implementation,
> which serializes the operation by disabling local interrupts.
> Consequently, HAVE_CMPXCHG_LOCAL is unset and users such as
> percpu_counter cannot use their cmpxchg-based fast paths.
> 
> Implement the 4-byte this_cpu_cmpxchg() operation with cmpxchg_local(),
> and provide the 8-byte operation on RV64. Pin execution while resolving
> the current CPU pointer so the LR/SC loop operates on one per-CPU
> instance, while allowing interrupt-context updates to race through the
> atomic operation.
> 
> Copy the old and new values to private temporaries before invoking
> cmpxchg_local(). This avoids collisions between local variable names in
> nested statement-expression macros.
> 
> The 1- and 2-byte operations continue to use the generic fallback.
> 
> Select HAVE_CMPXCHG_LOCAL and update the architecture feature matrix.
> 
> A percpu_counter_add() benchmark using the default batch value reduced
> the median time per operation by 77.3% (10 runs of 5,000,000
> operations).
> 
> In three 60-second stress-ng fork runs, median throughput increased by
> 4.6%. A 120-second combined fork and VM stress test completed without
> rss-counter errors or validation failures.
> 
> Signed-off-by: Xie Bo <xb@ultrarisc.com>

This patch seems to be missing 128-bit cmpxchg support.  Care to add it?


thanks,

- Paul

WARNING: multiple messages have this Message-ID (diff)
From: Paul Walmsley <pjw@kernel.org>
To: Xie Bo <xb@ultrarisc.com>
Cc: Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	 Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	 linux-riscv@lists.infradead.org, Dennis Zhou <dennis@kernel.org>,
	 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
	 Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	 linux-mm@kvack.org, linux-doc@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: Add native this_cpu_cmpxchg() support
Date: Thu, 20 Aug 2026 19:27:16 -0600 (MDT)	[thread overview]
Message-ID: <8b8cbb4a-474d-1de4-eaf2-dd8b4e6ca8ec@kernel.org> (raw)
In-Reply-To: <20260730094407.16588-1-xb@ultrarisc.com>

Hi, 

On Thu, 30 Jul 2026, Xie Bo wrote:

> RISC-V falls back to the generic this_cpu_cmpxchg() implementation,
> which serializes the operation by disabling local interrupts.
> Consequently, HAVE_CMPXCHG_LOCAL is unset and users such as
> percpu_counter cannot use their cmpxchg-based fast paths.
> 
> Implement the 4-byte this_cpu_cmpxchg() operation with cmpxchg_local(),
> and provide the 8-byte operation on RV64. Pin execution while resolving
> the current CPU pointer so the LR/SC loop operates on one per-CPU
> instance, while allowing interrupt-context updates to race through the
> atomic operation.
> 
> Copy the old and new values to private temporaries before invoking
> cmpxchg_local(). This avoids collisions between local variable names in
> nested statement-expression macros.
> 
> The 1- and 2-byte operations continue to use the generic fallback.
> 
> Select HAVE_CMPXCHG_LOCAL and update the architecture feature matrix.
> 
> A percpu_counter_add() benchmark using the default batch value reduced
> the median time per operation by 77.3% (10 runs of 5,000,000
> operations).
> 
> In three 60-second stress-ng fork runs, median throughput increased by
> 4.6%. A 120-second combined fork and VM stress test completed without
> rss-counter errors or validation failures.
> 
> Signed-off-by: Xie Bo <xb@ultrarisc.com>

This patch seems to be missing 128-bit cmpxchg support.  Care to add it?


thanks,

- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-08-21  1:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30  9:44 [PATCH] riscv: Add native this_cpu_cmpxchg() support Xie Bo
2026-07-30  9:44 ` Xie Bo
2026-08-21  1:27 ` Paul Walmsley [this message]
2026-08-21  1:27   ` Paul Walmsley
2026-08-21  3:07   ` [PATCH v2] " Xie Bo
2026-08-21  3:07     ` Xie Bo

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=8b8cbb4a-474d-1de4-eaf2-dd8b4e6ca8ec@kernel.org \
    --to=pjw@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=cl@gentwo.org \
    --cc=corbet@lwn.net \
    --cc=dennis@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tj@kernel.org \
    --cc=xb@ultrarisc.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.