Messages in this thread | | | From | Shakeel Butt <> | Date | Tue, 30 Jun 2020 12:25:56 -0700 | Subject | Re: [RFC][PATCH 0/8] Migrate Pages in lieu of discard |
| |
On Tue, Jun 30, 2020 at 11:51 AM Dave Hansen <dave.hansen@intel.com> wrote: > > On 6/30/20 11:36 AM, Shakeel Butt wrote: > >> This is part of a larger patch set. If you want to apply these or > >> play with them, I'd suggest using the tree from here. It includes > >> autonuma-based hot page promotion back to DRAM: > >> > >> http://lkml.kernel.org/r/c3d6de4d-f7c3-b505-2e64-8ee5f70b2118@intel.com > >> > >> This is also all based on an upstream mechanism that allows > >> persistent memory to be onlined and used as if it were volatile: > >> > >> http://lkml.kernel.org/r/20190124231441.37A4A305@viggo.jf.intel.com > >> > > I have a high level question. Given a reclaim request for a set of > > nodes, if there is no demotion path out of that set, should the kernel > > still consider the migrations within the set of nodes? > > OK, to be specific, we're talking about a case where we've arrived at > try_to_free_pages()
Yes.
> and, say, all of the nodes on the system are set in > sc->nodemask? Isn't the common case that all nodes are set in > sc->nodemask?
Depends on the workload but for normal users, yes.
> 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.
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.
| |