linux-kernel - Re: [PATCH v8 00/12] mm/demotion: Memory tiers and demotion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 25 Jul 2022 14:02:49 +0800
From:   "Huang, Ying" <ying.huang@...el.com>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     Wei Xu <weixugc@...gle.com>,
        Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>,
        Johannes Weiner <hannes@...xchg.org>,
        "Linux MM" <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Yang Shi" <shy828301@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Tim C Chen <tim.c.chen@...el.com>,
        Michal Hocko <mhocko@...nel.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Hesham Almatary <hesham.almatary@...wei.com>,
        Dave Hansen <dave.hansen@...el.com>,
        "Alistair Popple" <apopple@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        <jvgediya.oss@...il.com>
Subject: Re: [PATCH v8 00/12] mm/demotion: Memory tiers and demotion

Hi, Jonathan,

Jonathan Cameron <Jonathan.Cameron@...wei.com> writes:

> On Wed, 13 Jul 2022 16:17:21 +0800
> "Huang, Ying" <ying.huang@...el.com> wrote:
>
>> Wei Xu <weixugc@...gle.com> writes:

[snip]
>> >
>> > Th "memory type" and "abstract distance" concepts sound to me similar
>> > to the memory tier "rank" idea.  
>> 
>> Yes.  "abstract distance" is similar as "rank".
>> 
>> > We can have some well-defined type/distance/rank values, e.g. HBM,
>> > DRAM, CXL_DRAM, PMEM, CXL_PMEM, which a device can register with.  The
>> > memory tiers will build from these values.  It can be configurable to
>> > whether/how to collapse several values into a single tier.  
>> 
>> The memory types are registered by drivers (such as kmem_dax).  And the
>> distances can come from SLIT, HMAT, and other firmware or driver
>> specific information sources.
>> 
>> Per my understanding, this solution may make memory tier IDs more
>> unstable.  For example, the memory ID of a node may be changed after the
>> user override the distance of a memory type.  Although I think the
>> overriding should be a rare operations, will it be a real issue for your
>> use cases?
>
> Not sure how common it is, but I'm aware of systems that have dynamic
> access characteristics.  i.e. the bandwidth and latency of a access
> to a given memory device will change dynamically at runtime (typically
> due to something like hardware degradation / power saving etc).  Potentially
> leading to memory in use needing to move in 'demotion order'.  We could
> handle that with a per device tier and rank that changes...
>
> Just thought I'd throw that out there to add to the complexity ;)
> I don't consider it important to support initially but just wanted to
> point out this will only get more complex over time.
>

Thanks for your information!

If we make the mapping from the abstract distance range to the memory
tier ID stable at some degree, the memory tier ID can be stable at some
degree, e.g.,

abstract distance range         memory tier ID
1  -100                         0
101-200                         1
201-300                         2
301-400                         3
401-500                         4
500-                            5

Then if the abstract distance of a memory device changes at run time,
its memory tier ID will change.  But the memory tier ID of other memory
devices can be unchanged.

If so, the memory tier IDs are unstable mainly when we change the
mapping from the abstract distance range to memory tier ID.

Best Regards,
Huang, Ying