Re: [PATCH 0/4] [RFC] Migrate Pages in lieu of discard
From: Michal Hocko
Date: Tue Oct 22 2019 - 09:49:54 EST
On Fri 18-10-19 07:54:20, Dave Hansen wrote:
> On 10/18/19 12:44 AM, Michal Hocko wrote:
> > How does this compare to
> > http://lkml.kernel.org/r/1560468577-101178-1-git-send-email-yang.shi@xxxxxxxxxxxxxxxxx
> It's a _bit_ more tied to persistent memory and it appears a bit more
> tied to two tiers rather something arbitrarily deep. They're pretty
> similar conceptually although there are quite a few differences.
> For instance, what I posted has a static mapping for the migration path.
> If node A is in reclaim, we always try to allocate pages on node B.
> There are no restrictions on what those nodes can be. In Yang Shi's
> apporach, there's a dynamic search for a target migration node on each
> migration that follows the normal alloc fallback path. This ends up
> making migration nodes special.
As we have discussed at LSFMM this year and there seemed to be a goog
consensus on that, the resulting implementation should be as pmem
neutral as possible. After all node migration mode sounds like a
reasonable feature even without pmem. So I would be more inclined to the
normal alloc fallback path rather than a very specific and static
migration fallback path. If that turns out impractical then sure let's
come up with something more specific but I think there is quite a long
route there because we do not really have much of an experience with
this so far.
> There are also some different choices that are pretty arbitrary. For
> instance, when you allocation a migration target page, should you cause
> memory pressure on the target?
Those are details to really sort out and they require some
> To be honest, though, I don't see anything fatally flawed with it. It's
> probably a useful exercise to factor out the common bits from the two
> sets and see what we can agree on being absolutely necessary.
Makes sense. What would that be? Is there a real consensus on having the
new node_reclaim mode to be the configuration mechanism? Do we want to
support generic NUMA without any PMEM in place as well for starter?