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. 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
