On Thu, 25 Jan 2024, David Rientjes wrote: > This is **exactly** the type of discussion we're looking to have :) > > There are some things that I've chatted informally with folks about that > I'd like to bring to the forum: > > - Decoupling CPU migration from memory migration for NUMA Balancing (or > perhaps deprecating CPU migration entirely) > > - Allowing NUMA Balancing to do migration as part of a kthread > asynchronous to the NUMA hint fault, in kernel context > > - Abstraction for future hardware devices that can provide an expanded > view into page hotness that can be leveraged in different areas of the > kernel, including as a backend for NUMA Balanacing to replace NUMA > hint faults > > - Per-container support for configuring balancing and memory migration > > - Opting certain types of memory into NUMA Balancing (like tmpfs) while > leaving other types alone > > - Utilizing hardware accelerated memory migration as a replacement for > the traditional migrate_pages() path when available > It would be absolutely stunning if all of the above is non controversial :) I would imagine that there are some (perhaps strong) opinions polarized between "ok, this makes sense" and "ok, this seems crazy" for each one of these. Or, at least, "prove to me that this makes sense." We can definitely wait for this work group to be formed and then come back to the mailing list, but any early feedback on these would be much appreciated especially if the opinions are polarized toward the at least some of these being on the crazy side.
