Re: [PATCH v8 00/12] mm/demotion: Memory tiers and demotion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Jonathan,

Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> writes:

> On Wed, 13 Jul 2022 16:17:21 +0800
> "Huang, Ying" <ying.huang@xxxxxxxxx> wrote:
>
>> Wei Xu <weixugc@xxxxxxxxxx> 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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux