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

[Michal Hocko <mhocko@suse.com>]

On Tue 05-12-23 14:12:17, Srinivasulu Thanneeru wrote:
> 
> 
> On 12/5/2023 2:05 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 01:26:07, Srinivasulu Thanneeru wrote:
> > > 
> > > 
> > > On 12/4/2023 9:13 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 Fri 01-12-23 03:34:20, sthanneeru.opensrc@micron.com wrote:
> > > > > From: Srinivasulu Thanneeru <sthanneeru.opensrc@micron.com>
> > > > > 
> > > > > 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?
> > 
> > > 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?

-- 
Michal Hocko
SUSE Labs