Re: [EXT] Re: [RFC PATCH 0/2] Node migration between memory tiers

On 12/5/2023 2:21 PM, Michal Hocko wrote:

CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you recognize the sender and were expecting this message.


On Tue 05-12-23 14:12:17, Srinivasulu Thanneeru wrote:

quoted

On 12/5/2023 2:05 PM, Michal Hocko wrote:

quoted

CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you recognize the sender and were expecting this message.


On Tue 05-12-23 01:26:07, Srinivasulu Thanneeru wrote:

quoted

On 12/4/2023 9:13 PM, Michal Hocko wrote:

quoted

CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you recognize the sender and were expecting this message.


On Fri 01-12-23 03:34:20, sthanneeru.opensrc@micron.com wrote:

quoted

From: Srinivasulu Thanneeru <redacted>

The memory tiers feature allows nodes with similar memory types
or performance characteristics to be grouped together in a
memory tier. However, there is currently no provision for
moving a node from one tier to another on demand.

Could you expand on why this is really needed/necessary? What is the
actual usecase?

Hi Michal Hock,

Following two use-cases we have observed.
1. It is not accurate to group similar memory types in the same tier,
     because even similar memory types may have different speed grades.

Presumably they are grouped based on a HW configuration. Does that mean
that the configuration is wrong? Are you trying to workaround that by
this interface?

quoted

2. Some systems boots up with CXL devices and DRAM on the same memory-tier,
we need a way to move the CXL nodes to the correct tier from the user space.

Again, could you expand a bit more and explain why this cannot be
configured automatically?

Yes, in both cases above, if hardware not automatically populated properly,
in that case this interface would help to correct it from user space.

We had observed case-2 in our setups.

How hard it is to address this at the HW level?

Btw. this is really important piece of context that should be part of
the changelog. Quite honestly introducing user interfaces solely to
workaround HW issues seems a rather weak justification. Are there any
usecases you can think of where this would be useful?

I'm not sure how difficult to fix it in the hardware.

Sure, i will capture the use-cases in the change log, will be sending V2 
by changing interface from adistance_offset to memtier_overwrite to 
avoid complicated math for finding offset at user-level.

Thank you Michal Hocko for the feedback.

--
Michal Hocko
SUSE Labs