Re: [RFC PATCH 1/2] locking: add mutex_lock_nospin()

[David Laight <david.laight.linux@gmail.com>]

On Wed, 4 Mar 2026 23:30:40 -0500
Waiman Long <longman@redhat.com> wrote:

> On 3/4/26 10:08 PM, Yafang Shao wrote:
> > On Thu, Mar 5, 2026 at 11:00 AM Steven Rostedt <rostedt@goodmis.org> wrote:  
> >> On Thu, 5 Mar 2026 10:33:00 +0800
> >> Yafang Shao <laoar.shao@gmail.com> wrote:
> >>  
> >>> Other tools may also read available_filter_functions, requiring each
> >>> one to be patched individually to avoid this flaw—a clearly
> >>> impractical solution.  
> >> What exactly is the issue?  
> > It makes no sense to spin unnecessarily when it can be avoided. We
> > continuously improve the kernel to do the right thing—and unnecessary
> > spinning is certainly not the right thing.
> >  
> >> If a task does a while 1 in user space, it
> >> wouldn't be much different.  
> > The while loop in user space performs actual work, whereas useless
> > spinning does nothing but burn CPU cycles. My point is simple: if this
> > unnecessary spinning isn't already considered an issue, it should
> > be—it's something that clearly needs improvement.  
> 
> The whole point of optimistic spinning is to reduce the lock acquisition 
> latency. If the waiter sleeps, the unlock operation will have to wake up 
> the waiter which can have a variable latency depending on how busy the 
> system is at the time. Yes, it is burning CPU cycles while spinning, 
> Most workloads will gain performance with this optimistic spinning 
> feature. You do have a point that for system monitoring tools that 
> observe the system behavior, they shouldn't burn that much CPU times 
> that affect performance of real workload that the tools are monitoring.
> 
> BTW, you should expand the commit log of patch 1 to include the 
> rationale of why we should add this feature to mutex as the information 
> in the cover letter won't get included in the git log if this patch 
> series is merged. You should also elaborate in comment on under what 
> conditions should this this new mutex API be used.

Isn't changing mutex_lock() the wrong place anyway?
What you need is for the code holding the lock to indicate that
it isn't worth waiters spinning because the lock will be held
for a long time.

	David

> 
> Cheers,
> Longman
>