Re: [PATCH 11/11] arm64: sched/preempt: Enable PREEMPT_COUNT_64BIT

Boqun Feng <[email protected]> Fri, 8 May 2026 07:48:34 -0700
Newsgroups org.kernel.vger.linux-openrisc,org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
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 <[email protected]>
> > ---
> >  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)
> > 
> >