On Tue, Feb 06, 2024, David Woodhouse wrote: > On Tue, 2024-02-06 at 20:22 -0800, Sean Christopherson wrote: > > On Mon, Jan 15, 2024, Paul Durrant wrote: > > > From: Paul Durrant <pdurrant@xxxxxxxxxx> > > > > > > Taking a write lock on a pfncache will be disruptive if the cache is > > > > *Unnecessarily* taking a write lock. > > No. Taking a write lock will be disrupting. > > Unnecessarily taking a write lock will be unnecessarily disrupting. > > Taking a write lock on a Thursday will be disrupting on a Thursday. > > But the key is that if the cache is heavily used, the user gets > disrupted. If the invalidation is relevant, then this code is taking gpc->lock for write no matter what. The purpose of the changelog is to explain _why_ a patch adds value. > > Please save readers a bit of brain power > > and explain that this is beneificial when there are _unrelated_ invalidation. > > I don't understand what you're saying there. Paul's sentence did have > an implicit "...so do that less then", but that didn't take much brain > power to infer. I'm saying this: When processing mmu_notifier invalidations for gpc caches, pre-check for overlap with the invalidation event while holding gpc->lock for read, and only take gpc->lock for write if the cache needs to be invalidated. Doing a pre-check without taking gpc->lock for write avoids unnecessarily contending the lock for unrelated invalidations, which is very beneficial for caches that are heavily used (but rarely subjected to mmu_notifier invalidations). is much friendlier to readers than this: Taking a write lock on a pfncache will be disruptive if the cache is heavily used (which only requires a read lock). Hence, in the MMU notifier callback, take read locks on caches to check for a match; only taking a write lock to actually perform an invalidation (after a another check). Is it too much hand-holding, and bordering on stating the obvious? Maybe. But (a) a lot of people that read mailing lists and KVM code are *not* kernel experts, and (b) a changelog is written _once_, and read hundreds if not thousands of times. If we can save each reader even a few seconds, then taking an extra minute or two to write a more verbose changelog is a net win.
