From: "Huang, Ying" <ying.huang@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Wei Xu <weixugc@google.com>,
Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"Linux MM" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Yang Shi" <shy828301@gmail.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Tim C Chen <tim.c.chen@intel.com>,
Michal Hocko <mhocko@kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
Hesham Almatary <hesham.almatary@huawei.com>,
Dave Hansen <dave.hansen@intel.com>,
"Alistair Popple" <apopple@nvidia.com>,
Dan Williams <dan.j.williams@intel.com>,
<jvgediya.oss@gmail.com>
Subject: Re: [PATCH v8 00/12] mm/demotion: Memory tiers and demotion
Date: Mon, 25 Jul 2022 14:02:49 +0800 [thread overview]
Message-ID: <878rohzq46.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <20220719150032.000066a6@Huawei.com> (Jonathan Cameron's message of "Tue, 19 Jul 2022 15:00:32 +0100")
Hi, Jonathan,
Jonathan Cameron <Jonathan.Cameron@Huawei.com> writes:
> On Wed, 13 Jul 2022 16:17:21 +0800
> "Huang, Ying" <ying.huang@intel.com> wrote:
>
>> Wei Xu <weixugc@google.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
next prev parent reply other threads:[~2022-07-25 6:03 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-04 7:06 Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 01/12] mm/demotion: Add support for explicit memory tiers Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 02/12] mm/demotion: Move memory demotion related code Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 03/12] mm/demotion/dax/kmem: Set node's memory tier to MEMORY_TIER_PMEM Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 04/12] mm/demotion: Add hotplug callbacks to handle new numa node onlined Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 05/12] mm/demotion: Build demotion targets based on explicit memory tiers Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 06/12] mm/demotion: Expose memory tier details via sysfs Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 07/12] mm/demotion: Add per node memory tier attribute to sysfs Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 08/12] mm/demotion: Add pg_data_t member to track node memory tier details Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 09/12] mm/demotion: Demote pages according to allocation fallback order Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 10/12] mm/demotion: Update node_is_toptier to work with memory tiers Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 11/12] mm/demotion: Add documentation for memory tiering Aneesh Kumar K.V
2022-07-04 7:06 ` [PATCH v8 12/12] mm/demotion: Add sysfs ABI documentation Aneesh Kumar K.V
2022-07-04 15:00 ` [PATCH v8 00/12] mm/demotion: Memory tiers and demotion Matthew Wilcox
2022-07-05 3:45 ` Alistair Popple
2022-07-05 4:17 ` Aneesh Kumar K V
2022-07-05 4:29 ` Huang, Ying
2022-07-05 5:22 ` Aneesh Kumar K V
2022-07-12 1:16 ` Huang, Ying
2022-07-12 4:42 ` Aneesh Kumar K V
2022-07-12 5:09 ` Aneesh Kumar K V
2022-07-12 18:02 ` Yang Shi
2022-07-13 3:42 ` Huang, Ying
2022-07-13 6:38 ` Wei Xu
2022-07-13 6:39 ` Wei Xu
2022-07-13 7:25 ` Aneesh Kumar K V
2022-07-13 8:20 ` Huang, Ying
2022-07-12 6:59 ` Huang, Ying
2022-07-12 7:31 ` Aneesh Kumar K V
2022-07-12 8:48 ` Huang, Ying
2022-07-12 9:17 ` Aneesh Kumar K V
2022-07-13 2:59 ` Huang, Ying
2022-07-13 6:46 ` Wei Xu
2022-07-13 8:17 ` Huang, Ying
2022-07-19 14:00 ` Jonathan Cameron
2022-07-25 6:02 ` Huang, Ying [this message]
2022-07-13 9:44 ` Aneesh Kumar K.V
2022-07-13 9:40 ` Aneesh Kumar K.V
2022-07-14 4:56 ` Huang, Ying
2022-07-14 5:29 ` Aneesh Kumar K V
2022-07-14 7:21 ` Huang, Ying
2022-07-11 15:29 ` Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rohzq46.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.com \
--cc=Jonathan.Cameron@Huawei.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=apopple@nvidia.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave@stgolabs.net \
--cc=hannes@cmpxchg.org \
--cc=hesham.almatary@huawei.com \
--cc=jvgediya.oss@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=shy828301@gmail.com \
--cc=tim.c.chen@intel.com \
--cc=weixugc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox