On 3/5/26 4:32 AM, David Laight wrote:
On Wed, 4 Mar 2026 23:30:40 -0500
Waiman Long <[email protected]> wrote:
On 3/4/26 10:08 PM, Yafang Shao wrote:
On Thu, Mar 5, 2026 at 11:00 AM Steven Rostedt <[email protected]> wrote:
On Thu, 5 Mar 2026 10:33:00 +0800
Yafang Shao <[email protected]> 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.
I have actually thought about having a flag somewhere in the mutex
itself to indicate that optimistic spinning isn't needed. However the
owner field is running out of usable flag bits. The other option is to
add it to osq as it doesn't really need to use the full 32 bits for the
tail. In this case, we can just initialize the mutex to say that we
don't need optimistic spinning and no new mutex_lock() API will be needed.
Cheers,
Longman
