Hi Tejun, On Wed, 29 Mar 2023, Tejun Heo wrote: > On Mon, Mar 27, 2023 at 04:23:13PM -0700, Yosry Ahmed wrote: > > Tejun, if having the lock be non-irq is a non-starter for you, I can > > This is an actual hazard. We see in prod these unprotected locks causing > very big spikes in tail latencies and they can be tricky to root cause too > and given the way rstat lock is used it's highly likely to be involved in > those scenarios with the proposed change, so it's gonna be a nack from my > end. Butting in here, I'm fascinated. This is certainly not my area, I know nothing about rstat, but this is the first time I ever heard someone arguing for more disabling of interrupts rather than less. An interrupt coming in while holding a contended resource can certainly add to latencies, that I accept of course. But until now, I thought it was agreed best practice to disable irqs only regretfully, when strictly necessary. If that has changed, I for one want to know about it. How should we now judge which spinlocks should disable interrupts and which should not? Page table locks are currently my main interest - should those be changed? Thanks, Hugh
