On Fri, Mar 6, 2026 at 2:45 AM Waiman Long <[email protected]> wrote: > > On 3/5/26 1:34 PM, Waiman Long wrote: > > On 3/5/26 12:40 AM, Yafang Shao wrote: > >> On Thu, Mar 5, 2026 at 12:30 PM 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. > >> 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.
Perhaps I didn't phrase that well. I do understand that optimistic spinning is valuable in use cases where we wouldn't want to disable CONFIG_MUTEX_SPIN_ON_OWNER. > 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. > > BTW, for any new mutex API introduced, you should also provide an > equivalent version in kernel/locking/rtmutex_api.c for PREEMPT_RT kernel. Thanks for the suggestion. -- Regards Yafang
