On Tue, Apr 16, 2019 at 04:17:44PM -0700, Yang Shi wrote: > On 4/16/19 4:04 PM, Dave Hansen wrote: > > On 4/16/19 2:59 PM, Yang Shi wrote: > > > On 4/16/19 2:22 PM, Dave Hansen wrote: > > > > Keith Busch had a set of patches to let you specify the demotion order > > > > via sysfs for fun. The rules we came up with were: > > > > 1. Pages keep no history of where they have been > > > > 2. Each node can only demote to one other node > > > Does this mean any remote node? Or just DRAM to PMEM, but remote PMEM > > > might be ok? > > In Keith's code, I don't think we differentiated. We let any node > > demote to any other node you want, as long as it follows the cycle rule. > > I recall Keith's code let the userspace define the target node. Right, you have to opt-in in my original proposal since it may be a bit presumptuous of the kernel to decide how a node's memory is going to be used. User applications have other intentions for it. It wouldn't be too difficult to make HMAT to create a reasonable initial migration graph too, and that can also make that an opt-in user choice. > Anyway, we may need add one rule: not migrate-on-reclaim from PMEM > node. Demoting from PMEM to DRAM sounds pointless. I really don't think we should be making such hard rules on PMEM. It makes more sense to consider performance and locality for migration rules than on a persistence attribute.
