On Tue, Aug 6, 2024 at 10:23 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Thu, Aug 01, 2024 at 04:13:40PM -0700, James Houghton wrote: > > --- a/include/linux/mmu_notifier.h > > +++ b/include/linux/mmu_notifier.h > > @@ -106,6 +106,18 @@ struct mmu_notifier_ops { > > * clear_young is a lightweight version of clear_flush_young. Like the > > * latter, it is supposed to test-and-clear the young/accessed bitflag > > * in the secondary pte, but it may omit flushing the secondary tlb. > > + * > > + * The fast_only parameter indicates that this call should not block, > > + * and this function should not cause other MMU notifier calls to > > + * block. Usually this means that the implementation should be > > + * lockless. > > + * > > + * When called with fast_only, this notifier will be a no-op unless > > + * has_fast_aging is set on the struct mmu_notifier. > > If you add a has_fast_aging I wonder if it is better to introduce new > ops instead? The semantics are a bit easier to explain that way v5 implemented these with a new op[1]. *Just* having the new op is kind of problematic -- we have yet another op to do something very similar to what already exists. We are left with two options: consolidate everything into a single notifier[2] or add a new parameter to test/clear_young()[3]. The latter, implemented in this v6, is somewhat simpler to implement (fewer LoC, reduces some duplication in KVM), though it does indeed make the explanation for test/clear_young() slightly more complex. I don't feel very strongly, but unless you do, I think I just ought to stick with how the v6 does it. :) Thanks Jason! [1]: https://lore.kernel.org/linux-mm/20240611002145.2078921-5-jthoughton@xxxxxxxxxx/ [2]: https://lore.kernel.org/linux-mm/CADrL8HVHcKSW3hiHzKTit07gzo36jtCZCnM9ZpueyifgNdGggw@xxxxxxxxxxxxxx/ [3]: https://lore.kernel.org/linux-mm/CADrL8HXhGFWwHt728Bg15x1YxJmS=WD8z=KJc_Koaah=OvHDwg@xxxxxxxxxxxxxx/