On Sun, Jul 06, 2025 at 11:12:35PM -0700, Hugh Dickins wrote: > Applause! > > No way shall I review this, but each time I've seen an mremap series > from Lorenzo go by, I've wanted to say "but wouldn't it be better to..."; > but it felt too impertinent to prod you in a direction I'd never dare > take myself (and quite likely that you had already tried, but found it > fundamentally impossible). > > Thank you, yes, this is a very welcome step forward. Thank you that's very kind of you! :) and please, by all means do feel free to prod or to give your thoughts and opinions on things, they're very welcome and appreciated! With respect to this series, I think it really underlines what a difference refactoring can make to being able to have code do something new - prior to my last refactoring series and the refactoring bits here I just don't think it would have been possible. WRT to the relocate anon series - I thought it'd be interesting to talk about why it didn't work out a bit in case you/others might find it interesting: Indeed, while I'd like us to more efficiently process VMAs in the anon_vma case, it turns out there's simply too many moving parts for it to be feasible at this time - I reached the point of dealing with many many edge cases addressing the points David raised about folios in the swap cache and migration entries (which might also fail to migrate), having gone to great lengths to avoid having a not-reliable undo path. I'd even invented a new means of 'hiding' anon_vma's from the rmap walker, and did split folio work up front and and and :) But then there came a point where unavoidably I'd ahave to do a split folio mid-way through the operation and GUP fast could race and increment a refcount that'd break that and... it was just obvious this approach wasn't workable, and was far too fragile. Important to accept when one reaches such a point, but it wasn't a waste, as a. there's a lot that can be reused and applied later, b. I learned a great deal, c. it helped further my research in this area. I think overall efforts in this direction will require a more ambitious rework of the anon_vma stuff, something I intend to do :) but it'll all be done incrementally, with a great deal of care, and obviously working with the community throughout. > > Hugh Cheers, Lorenzo
