On 6/30/20 12:25 PM, Shakeel Butt wrote: >> Since there is never a demotion path out of the set of >> all nodes, the common case would be that there is no demotion path out >> of a reclaim node set. >> >> If that's true, I'd say that the kernel still needs to consider >> migrations even within the set. > In my opinion it should be a user defined policy but I think that > discussion is orthogonal to this patch series. As I understand, this > patch series aims to add the migration-within-reclaim infrastructure, > IMO the policies, optimizations, heuristics can come later. Yes, this should be considered to add the infrastructure and one _simple_ policy implementation which sets up migration away from nodes with CPUs to more distant nodes without CPUs. This simple policy will be useful for (but not limited to) volatile-use persistent memory like Intel's Optane DIMMS. > BTW is this proposal only for systems having multi-tiers of memory? > Can a multi-node DRAM-only system take advantage of this proposal? For > example I have a system with two DRAM nodes running two jobs > hardwalled to each node. For each job the other node is kind of > low-tier memory. If I can describe the per-job demotion paths then > these jobs can take advantage of this proposal during occasional > peaks. I don't see any reason it could not work there. There would just need to be a way to set up a different demotion path policy that what was done here.
