All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@gentwo.de>
To: Guo Ren <guoren@kernel.org>
Cc: tj@kernel.org, palmer@dabbelt.com, will@kernel.org,
	catalin.marinas@arm.com, peterz@infradead.org, arnd@arndb.de,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	Guo Ren <guoren@linux.alibaba.com>
Subject: Re: [RFC PATCH 1/4] vmstat: percpu: Rename HAVE_CMPXCHG_LOCAL to HAVE_CMPXCHG_PERCPU_BYTE
Date: Mon, 8 Aug 2022 11:31:44 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2208081119230.411952@gentwo.de> (raw)
In-Reply-To: <20220808080600.3346843-2-guoren@kernel.org>

On Mon, 8 Aug 2022, guoren@kernel.org wrote:

> The name HAVE_CMPXCHG_LOCAL is confused with using cmpxchg_local, but
> vmstat needs this_cpu_cmpxchg_1. Rename would clarify the meaning, and
> maybe we could remove cmpxchg(64)_local API (Only drivers/iommu/intel
> used) in the future.

HAVE_CMPXCHG_LOCAL indicates that cmpxchg_local() is available.

The term LOCAL is important because that has traditionally signified an
operation that has an atomic nature that only works on the local core.

cmpxchg local is used in slub too in the form of this_cpu_cmpxchg_double.

But there is the other naming using this_cpu.....

Maybe rename to

	HAVE_THIS_CPU_CMPXCHG ?

and clean up all the other mentions of "local" in the source too?

There is also a local.h header around somewhere

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@gentwo.de>
To: Guo Ren <guoren@kernel.org>
Cc: tj@kernel.org, palmer@dabbelt.com, will@kernel.org,
	 catalin.marinas@arm.com, peterz@infradead.org, arnd@arndb.de,
	 linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-riscv@lists.infradead.org,
	Guo Ren <guoren@linux.alibaba.com>
Subject: Re: [RFC PATCH 1/4] vmstat: percpu: Rename HAVE_CMPXCHG_LOCAL to HAVE_CMPXCHG_PERCPU_BYTE
Date: Mon, 8 Aug 2022 11:31:44 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2208081119230.411952@gentwo.de> (raw)
In-Reply-To: <20220808080600.3346843-2-guoren@kernel.org>

On Mon, 8 Aug 2022, guoren@kernel.org wrote:

> The name HAVE_CMPXCHG_LOCAL is confused with using cmpxchg_local, but
> vmstat needs this_cpu_cmpxchg_1. Rename would clarify the meaning, and
> maybe we could remove cmpxchg(64)_local API (Only drivers/iommu/intel
> used) in the future.

HAVE_CMPXCHG_LOCAL indicates that cmpxchg_local() is available.

The term LOCAL is important because that has traditionally signified an
operation that has an atomic nature that only works on the local core.

cmpxchg local is used in slub too in the form of this_cpu_cmpxchg_double.

But there is the other naming using this_cpu.....

Maybe rename to

	HAVE_THIS_CPU_CMPXCHG ?

and clean up all the other mentions of "local" in the source too?

There is also a local.h header around somewhere

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

  reply	other threads:[~2022-08-08  9:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08  8:05 [RFC PATCH 0/4] riscv: Add basic percpu operations guoren
2022-08-08  8:05 ` guoren
2022-08-08  8:05 ` [RFC PATCH 1/4] vmstat: percpu: Rename HAVE_CMPXCHG_LOCAL to HAVE_CMPXCHG_PERCPU_BYTE guoren
2022-08-08  8:05   ` guoren
2022-08-08  9:31   ` Christoph Lameter [this message]
2022-08-08  9:31     ` Christoph Lameter
2022-08-09  2:58     ` Guo Ren
2022-08-09  2:58       ` Guo Ren
2022-08-08  8:05 ` [RFC PATCH 2/4] arm64: percpu: Use generic PERCPU_RW_OPS guoren
2022-08-08  8:05   ` guoren
2022-08-08  8:05 ` [RFC PATCH 3/4] riscv: percpu: Implement this_cpu operations guoren
2022-08-08  8:05   ` guoren
2022-08-08  8:06 ` [RFC PATCH 4/4] riscv: cmpxchg: Remove unused cmpxchg(64)_local guoren
2022-08-08  8:06   ` guoren

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=alpine.DEB.2.22.394.2208081119230.411952@gentwo.de \
    --to=cl@gentwo.de \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=guoren@kernel.org \
    --cc=guoren@linux.alibaba.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    --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.