Linux s390 Architecture development
 help / color / mirror / Atom feed
From: Boqun Feng <boqun@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Jonas Bonn" <jonas@southpole.se>,
	"Stefan Kristiansson" <stefan.kristiansson@saunalahti.fi>,
	"Stafford Horne" <shorne@gmail.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Sven Schnelle" <svens@linux.ibm.com>,
	"Thomas Gleixner" <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Juri Lelli" <juri.lelli@redhat.com>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Dietmar Eggemann" <dietmar.eggemann@arm.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Ben Segall" <bsegall@google.com>, "Mel Gorman" <mgorman@suse.de>,
	"Valentin Schneider" <vschneid@redhat.com>,
	"K Prateek Nayak" <kprateek.nayak@amd.com>,
	"Waiman Long" <longman@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Miguel Ojeda" <ojeda@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Jinjie Ruan" <ruanjinjie@huawei.com>,
	"Ada Couprie Diaz" <ada.coupriediaz@arm.com>,
	"Lyude Paul" <lyude@redhat.com>,
	"Sohil Mehta" <sohil.mehta@intel.com>,
	"Pawan Gupta" <pawan.kumar.gupta@linux.intel.com>,
	"Xin Li (Intel)" <xin@zytor.com>,
	"Sean Christopherson" <seanjc@google.com>,
	"Nikunj A Dadhania" <nikunj@amd.com>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Yury Norov" <ynorov@nvidia.com>,
	"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-openrisc@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-arch@vger.kernel.org,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 11/11] arm64: sched/preempt: Enable PREEMPT_COUNT_64BIT
Date: Fri, 8 May 2026 07:48:34 -0700	[thread overview]
Message-ID: <af33wq5R09HWVE84@tardis.local> (raw)
In-Reply-To: <af2dPMW97tNOWuGF@J2N7QTR9R3>

On Fri, May 08, 2026 at 09:22:20AM +0100, Mark Rutland wrote:
> Hi Boqun,
> 
> I have a question at the end, with some context for other reviewers
> before that.
> 

Thank you for adding the context.

> On Thu, May 07, 2026 at 09:21:11PM -0700, Boqun Feng wrote:
> > ARM64 already uses 64bit preempt count and the need reschedule bit is
> > maintained in a separate 32bit than the preempt count. 
> 
> For the benefit of those reading the list, arm64 has a separate 32-bit
> count and a 32-bit field for need_resched, which are unioned together as
> a composite 64-bit value:
> 
> 	union {
> 		u64             preempt_count;  /* 0 => preemptible, <0 => bug */
> 		struct {
> 			u32     count;
> 			u32     need_resched;
> 		} preempt;
> 	};
> 
> All of our "count" operations work on the 32-bit count, e.g.
> 
> 	static inline int preempt_count(void)
> 	{
> 		return READ_ONCE(current_thread_info()->preempt.count);
> 	}
> 
> 
> 	static inline void __preempt_count_add(int val)
> 	{
> 		u32 pc = READ_ONCE(current_thread_info()->preempt.count);
> 		pc += val;
> 		WRITE_ONCE(current_thread_info()->preempt.count, pc);
> 	}
> 
> 	static inline void __preempt_count_sub(int val)
> 	{
> 		u32 pc = READ_ONCE(current_thread_info()->preempt.count);
> 		pc -= val;
> 		WRITE_ONCE(current_thread_info()->preempt.count, pc);
> 	}
> 
> ... but some operations use the 64-bit 'preempt_count' field from the union, e.g.
> 
> 	static inline bool should_resched(int preempt_offset)
> 	{
> 		u64 pc = READ_ONCE(current_thread_info()->preempt_count);
> 		return pc == preempt_offset;
> 	}	
> 
> > Therefore preempt count has enough bits to represent 16 level of NMI
> > nesting, hence enable it for ARM64. This saves a per-CPU variable and
> > additional instructions in the NMI path.
> 
> This might be true, but I think the name "PREEMPT_COUNT_64BIT" is
> misleading given the above. What exactly does PREEMPT_COUNT_64BIT tell
> core code it can do?

It tells the core code that all 32bit of preempt_count() can be used.

> 
> If this is just telling core code that it doesn't need ot reserve space
> in preempt_count for the resched bits, can this be called something
> else, e.g. HAS_SEPARATE_PREEMPT_RESCHED_BITS?

You are right on that the resched bit detail is a major difference
between PREEMPT_COUNT_64BIT=y or n. I haven't gone that far to resolve
the #1 difficult issue in programming (i.e. naming) ;-)
HAS_SEPARATE_PREEMPT_RESCHED_BITS seems reasonable, I will use it if no
other better ideas. Thanks!

Regards,
Boqun

> 
> Mark.
> 
> > 
> > Signed-off-by: Boqun Feng <boqun@kernel.org>
> > ---
> >  arch/arm64/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index fe60738e5943..1ed5173872fc 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -248,6 +248,7 @@ config ARM64
> >  	select PCI_SYSCALL if PCI
> >  	select POWER_RESET
> >  	select POWER_SUPPLY
> > +	select PREEMPT_COUNT_64BIT
> >  	select SPARSE_IRQ
> >  	select SWIOTLB
> >  	select SYSCTL_EXCEPTION_TRACE
> > -- 
> > 2.50.1 (Apple Git-155)
> > 
> > 

  reply	other threads:[~2026-05-08 14:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08  4:21 [PATCH 00/11] Refcounted interrupt disable and SpinLockIrq for rust (Part 1) Boqun Feng
2026-05-08  4:21 ` [PATCH 01/11] preempt: Introduce HARDIRQ_DISABLE_BITS Boqun Feng
2026-05-08  4:21 ` [PATCH 02/11] preempt: Track NMI nesting to separate per-CPU counter Boqun Feng
2026-05-08  4:21 ` [PATCH 03/11] preempt: Introduce __preempt_count_{sub, add}_return() Boqun Feng
2026-05-09 18:09   ` Heiko Carstens
2026-05-08  4:21 ` [PATCH 04/11] openrisc: Include <linux/cpumask.h> in smp.h Boqun Feng
2026-05-08  4:21 ` [PATCH 05/11] irq & spin_lock: Add counted interrupt disabling/enabling Boqun Feng
2026-05-08  4:21 ` [PATCH 06/11] irq: Add KUnit test for refcounted interrupt enable/disable Boqun Feng
2026-05-08  4:21 ` [PATCH 07/11] locking: Switch to _irq_{disable,enable}() variants in cleanup guards Boqun Feng
2026-05-08  4:21 ` [PATCH 08/11] sched: Remove the unused preempt_offset parameter of __cant_sleep() Boqun Feng
2026-05-08  4:21 ` [PATCH 09/11] sched: Avoid signed comparison of preempt_count() in __cant_migrate() Boqun Feng
2026-05-08  4:21 ` [PATCH 10/11] preempt: Introduce PREEMPT_COUNT_64BIT Boqun Feng
2026-05-08  4:21 ` [PATCH 11/11] arm64: sched/preempt: Enable PREEMPT_COUNT_64BIT Boqun Feng
2026-05-08  8:22   ` Mark Rutland
2026-05-08 14:48     ` Boqun Feng [this message]
2026-05-09 18:12 ` [PATCH 00/11] Refcounted interrupt disable and SpinLockIrq for rust (Part 1) Heiko Carstens
2026-05-09 18:21   ` Boqun Feng

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=af33wq5R09HWVE84@tardis.local \
    --to=boqun@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=ada.coupriediaz@arm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aliceryhl@google.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bigeasy@linutronix.de \
    --cc=bjorn3_gh@protonmail.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=dakr@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gary@garyguo.net \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=joelagnelf@nvidia.com \
    --cc=jonas@southpole.se \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-openrisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=nikunj@amd.com \
    --cc=ojeda@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=ruanjinjie@huawei.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=seanjc@google.com \
    --cc=shorne@gmail.com \
    --cc=sohil.mehta@intel.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=svens@linux.ibm.com \
    --cc=tglx@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    --cc=ynorov@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox