Re: [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of discard

[Dave Hansen]

On 6/30/20 10:41 PM, David Rientjes wrote:
> Maybe the strongest advantage of the node abstraction is the ability to 
> use autonuma and migrate_pages()/move_pages() API for moving pages 
> explicitly?  Mempolicies could be used for migration to "top-tier" memory, 
> i.e. ZONE_NORMAL or ZONE_MOVABLE, instead.

I totally agree that we _could_ introduce this new memory class as a zone.

Doing it as nodes is pretty natural since the firmware today describes
both slow (versus DRAM) and fast memory as separate nodes.  It also
means that apps can get visibility into placement with existing NUMA
tooling and ABIs.  To me, those are the two strongest reasons for PMEM.

Looking to the future, I don't think the zone approach scales.  I know
folks want to build stuff within a single socket which is a mix of:

1. High-Bandwidth, on-package memory (a la MCDRAM)
2. DRAM
3. DRAM-cached PMEM (aka. "memory mode" PMEM)
4. Non-cached PMEM

Right now, #1 doesn't exist on modern platform  and #3/#4 can't be mixed
(you only get 3 _or_ 4 at once).  I'd love to provide something here
that Intel can use to build future crazy platform configurations that
don't require kernel enabling.