On Fri, Mar 6, 2026 at 3:00 AM Waiman Long <[email protected]> wrote: > > 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.
True. Introducing a new MUTEX_FLAGS would likely require a substantial refactor of the mutex code, which may not be worth it. > 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. I believe a new mutex_lock() variant would be clearer and easier to understand. It also has the advantage of requiring minimal changes to the existing mutex code. -- Regards Yafang
