From: Gregory Price <gregory.price@memverge.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: sthanneeru.opensrc@micron.com, linux-cxl@vger.kernel.org,
linux-mm@kvack.org, sthanneeru@micron.com,
aneesh.kumar@linux.ibm.com, dan.j.williams@intel.com,
mhocko@suse.com, tj@kernel.org, john@jagalactic.com,
emirakhur@micron.com, vtavarespetr@micron.com,
Ravis.OpenSrc@micron.com, Jonathan.Cameron@huawei.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/2] Node migration between memory tiers
Date: Fri, 15 Dec 2023 12:42:56 -0500 [thread overview]
Message-ID: <ZXyQIJOim1+tE0Qr@memverge.com> (raw)
In-Reply-To: <87cyv8qcqk.fsf@yhuang6-desk2.ccr.corp.intel.com>
On Fri, Dec 15, 2023 at 01:02:59PM +0800, Huang, Ying wrote:
> <sthanneeru.opensrc@micron.com> writes:
>
> > =============
> > Version Notes:
> >
> > V2 : Changed interface to memtier_override from adistance_offset.
> > memtier_override was recommended by
> > 1. John Groves <john@jagalactic.com>
> > 2. Ravi Shankar <ravis.opensrc@micron.com>
> > 3. Brice Goglin <Brice.Goglin@inria.fr>
>
> It appears that you ignored my comments for V1 as follows ...
>
> https://lore.kernel.org/lkml/87o7f62vur.fsf@yhuang6-desk2.ccr.corp.intel.com/
> https://lore.kernel.org/lkml/87jzpt2ft5.fsf@yhuang6-desk2.ccr.corp.intel.com/
> https://lore.kernel.org/lkml/87a5qp2et0.fsf@yhuang6-desk2.ccr.corp.intel.com/
>
Not speaking for the group, just chiming in because i'd discussed it
with them.
"Memory Type" is a bit nebulous. Is a Micron Type-3 with performance X
and an SK Hynix Type-3 with performance Y a "Different type", or are
they the "Same Type" given that they're both Type 3 backed by some form
of DDR? Is socket placement of those devices relevant for determining
"Type"? Is whether they are behind a switch relevant for determining
"Type"? "Type" is frustrating when everything we're talking about
managing is "Type-3" with difference performance.
A concrete example:
To the system, a Multi-Headed Single Logical Device (MH-SLD) looks
exactly the same as an standard SLD. I may want to have some
combination of local memory expansion devices on the majority of my
expansion slots, but reserve 1 slot on each socket for a connection to
the MH-SLD. As of right now: There is no good way to differentiate the
devices in terms of "Type" - and even if you had that, the tiering
system would still lump them together.
Similarly, an initial run of switches may or may not allow enumeration
of devices behind it (depends on the configuration), so you may end up
with a static numa node that "looks like" another SLD - despite it being
some definition of "GFAM". Do number of hops matter in determining
"Type"?
So I really don't think "Type" is useful for determining tier placement.
As of right now, the system lumps DRAM nodes as one tier, and pretty
much everything else as "the other tier". To me, this patch set is an
initial pass meant to allow user-control over tier composition while
the internal mechanism is sussed out and the environment develops.
In general, a release valve that lets you redefine tiers is very welcome
for testing and validation of different setups while the industry evolves.
Just my two cents.
~Gregory
> --
> Best Regards,
> Huang, Ying
>
next prev parent reply other threads:[~2023-12-15 17:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-13 17:53 [RFC PATCH v2 0/2] Node migration between memory tiers sthanneeru.opensrc
2023-12-13 17:53 ` [PATCH 1/2] base/node: Add sysfs for memtier_override sthanneeru.opensrc
2023-12-13 17:53 ` [PATCH 2/2] memory tier: Support node migration between tiers sthanneeru.opensrc
2023-12-15 5:02 ` [RFC PATCH v2 0/2] Node migration between memory tiers Huang, Ying
2023-12-15 17:42 ` Gregory Price [this message]
2023-12-18 5:55 ` Huang, Ying
2024-01-03 5:26 ` [EXT] " Srinivasulu Thanneeru
2024-01-03 6:07 ` Huang, Ying
2024-01-03 7:56 ` Srinivasulu Thanneeru
2024-01-03 8:29 ` Huang, Ying
2024-01-03 8:47 ` Srinivasulu Thanneeru
2024-01-04 6:05 ` Huang, Ying
2024-01-08 17:04 ` Gregory Price
2024-01-09 3:41 ` Huang, Ying
2024-01-09 15:50 ` Jonathan Cameron
2024-01-09 17:59 ` Gregory Price
2024-01-10 0:28 ` [External] " Hao Xiang
2024-01-10 14:18 ` Jonathan Cameron
2024-01-10 19:29 ` Hao Xiang
2024-01-12 7:00 ` Huang, Ying
2024-01-12 8:14 ` Hao Xiang
2024-01-15 1:24 ` Huang, Ying
2024-01-10 5:47 ` Huang, Ying
2024-01-10 14:11 ` Jonathan Cameron
2024-01-10 6:06 ` Huang, Ying
2024-01-09 17:34 ` Gregory Price
2023-12-18 8:56 ` Srinivasulu Thanneeru
2023-12-19 3:57 ` Huang, Ying
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=ZXyQIJOim1+tE0Qr@memverge.com \
--to=gregory.price@memverge.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Ravis.OpenSrc@micron.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=emirakhur@micron.com \
--cc=john@jagalactic.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=sthanneeru.opensrc@micron.com \
--cc=sthanneeru@micron.com \
--cc=tj@kernel.org \
--cc=vtavarespetr@micron.com \
--cc=ying.huang@intel.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