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 experimentation to. > 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? Thanks! -- Michal Hocko SUSE Labs