>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@xxxxxxxxxx wrote:
>> > > > > From: Srinivasulu Thanneeru <sthanneeru.opensrc@xxxxxxxxxx>
>> > > > >
>> > > > > 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
Hello Michal Hocko,
It will be useful if we want interleave weights to be applied on memory tiers
instead of nodes.
Also, for near memory processing use cases where some accelerator would like
to have hot pages migrated to a different node with HBM, pmem or CXL instead of
CPU attached memory for performing it's operations quicker.
There was a prior discussion on this functionality in a previous thread, where
Huang Ying thought this might be a useful feature to overcome limitations of
systems where nodes with different bandwidth characteristics are grouped in
a single tier.
https://lore.kernel.org/lkml/87a5rw1wu8.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
--
Best Regards,
Ravi Jonnalagadda
