On Thu, Jun 11, 2026 at 05:00:49PM +0100, Lorenzo Stoakes wrote: > Hi Huang, > > You seem to be replacing the file rmap altogether here, so you really ought > to have sent this as an RFC so we could discuss it as a community first. No problem.
> > Especially so as Pedro had publicly mentioned his plans to implement > something similar here, so coordination would have been appreciated. Yes. I am very happy to work with Pedro. > > Anyway, as Pedro has pointed out, the code is overly complicated, it's far > too configurable (not always a good thing), and the locking implementation > is questionable. I can make the code more simple. :) > > You seem to be adding a whole bunch of open-coded complexity too, which is > not something we want. Abstraction is key for the rmap. > > You're also not adding any kdoc comments or really many comments at all, > and you've not added any tests (though perhaps it's difficult given how > core this is). Got it. > > So I would suggest that perhaps any respin should be sent as an RFC so we > can engage in that conversation and ensure we're all on the same page? > > Especially since Pedro plans to send an alternative, simpler, solution I > believe. > > It's also not helpful that you haven't examined the non-NUMA case :) > perhaps your particular server behaves a certain way that this approach > aids, but regresses other NUMA configurations? emm. I ever hoped someone can help me to test this patch set on the non-NUMA server. It seems I should find some non-NUMA server before I send out the patch set. :) > > We'd really need to be sure of this before accepting invasive changes like > this. Okay. Thanks Huang Shijie
