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

[Waiman Long]

On 3/5/26 12:40 AM, Yafang Shao wrote:
> On Thu, Mar 5, 2026 at 12:30 PM Waiman Long <longman@xxxxxxxxxx> wrote:
> > On 3/4/26 10:08 PM, Yafang Shao wrote:
> > > On Thu, Mar 5, 2026 at 11:00 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > > > On Thu, 5 Mar 2026 10:33:00 +0800
> > > > Yafang Shao <laoar.shao@xxxxxxxxx> 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.
> Exactly. ftrace is intended for debugging and should not significantly
> impact real workloads. Therefore, it's reasonable to make it sleep if
> it cannot acquire the lock immediately, rather than spinning and
> consuming CPU cycles.

Your patch series use wordings that give a negative connotation about 
optimistic spinning making it look like a bad thing. In fact, it is just 
a request for a new mutex API for use cases where they can suffer higher 
latency in order to minimize the system overhead they incur. So don't 
bad-mouth optimistic spinning and emphasize the use cases you want to 
support with the new API in your next version.

My 2 cents.

Cheers,
Longman