On Tue, Jun 11, 2024 at 10:50 AM James Houghton <jthoughton@xxxxxxxxxx> wrote: > > On Mon, Jun 10, 2024 at 10:34 PM Yu Zhao <yuzhao@xxxxxxxxxx> wrote: > > > > On Mon, Jun 10, 2024 at 6:22 PM James Houghton <jthoughton@xxxxxxxxxx> wrote: > > > > > > This new notifier is for multi-gen LRU specifically > > > > Let me call it out before others do: we can't be this self-serving. > > > > > as it wants to be > > > able to get and clear age information from secondary MMUs only if it can > > > be done "fast". > > > > > > By having this notifier specifically created for MGLRU, what "fast" > > > means comes down to what is "fast" enough to improve MGLRU's ability to > > > reclaim most of the time. > > > > > > Signed-off-by: James Houghton <jthoughton@xxxxxxxxxx> > > > > If we'd like this to pass other MM reviewers, especially the MMU > > notifier maintainers, we'd need to design a generic API that can > > benefit all the *existing* users: idle page tracking [1], DAMON [2] > > and MGLRU. > > > > Also I personally prefer to extend the existing callbacks by adding > > new parameters, and on top of that, I'd try to consolidate the > > existing callbacks -- it'd be less of a hard sell if my changes result > > in less code, not more. > > > > (v2 did all these, btw.) > > I think consolidating the callbacks is cleanest, like you had it in > v2. I really wasn't sure about this change honestly, but it was my > attempt to incorporate feedback like this[3] from v4. I'll consolidate > the callbacks like you had in v2. Only if you think updating the MMU notifier API is overall the best option. As I said earlier, I don't mind not doing the extra work, i.e., the bitmap/_fast_only parameters and the _FAST_YOUNG return value, as long as we know where we win and lose, i.e., simplicity and regressions. I would call all the potential regressions (the nested VM case, the arm64 case and the memcached benchmark) minor, compared with what we got from v2. But my opinion doesn't really matter much because I'm not your customer :)
