On Wed, 4 Mar 2026 15:57:42 -0500 Steven Rostedt <[email protected]> wrote:
> On Wed, 4 Mar 2026 09:54:15 +0000 > David Laight <[email protected]> wrote: > > > That might still be an issue if a high priority process is spinning. > > But a %sys spike doesn't imply a latency spike. > > > > Is this using the osq_lock.c code? > > That will have problems on overprovisioned VMs, it tries to find out > > whether the hypervisor has switched out - but ISTR that is flawed. > > > > In reality a spin lock shouldn't be held for long enough to cause > > any kind latency issue. > > So something in the code that reads the list of filter functions > > needs to be done differently so that the lock isn't held for as long. > > It's not a spinlock, it's an adaptive mutex which spins while the owner of > the mutex is also still running on the CPU. If the spinner CPU triggers a > NEED_RESCHED or the owner goes to sleep, the spinner stops spinning and > goes to sleep too. I think half my brain knew that - otherwise I wouldn't have mentioned the osq_lock.c code. That all reminded me I've a patch that optimises that code a bit. But I do remember thinking it ought to have a 'I been spinning long enough, time to sleep' path. David > > Honestly, this still looks like a non-issue or a corner case that I don't > think requires these changes. > > This looks like one of those "Patient: Doctor it hurts me when I do this. > Doctor: Then don't do that." cases. > > Why is a production system having multiple users cat > avaliable_filter_functions to begin with? > > -- Steve
