lkml.org 
[lkml]   [2020]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of discard
    From
    Date
    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.

    \
     
     \ /
      Last update: 2020-07-01 17:16    [W:2.938 / U:0.256 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site