lkml.org 
[lkml]   [2022]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 1/9] mm/demotion: Add support for explicit memory tiers
From
Date
On Thu, 2022-06-16 at 10:17 +0530, Aneesh Kumar K V wrote:
> On 6/16/22 9:15 AM, Wei Xu wrote:
> > On Wed, Jun 15, 2022 at 6:11 PM Ying Huang <ying.huang@intel.com> wrote:
> > >
> > > On Tue, 2022-06-14 at 14:56 -0400, Johannes Weiner wrote:
> > > > On Tue, Jun 14, 2022 at 01:31:37PM +0530, Aneesh Kumar K V wrote:
>
> ....
>
> > > As Jonathan Cameron pointed, we may need the memory tier ID to be
> > > stable if possible. I know this isn't a easy task. At least we can
> > > make the default memory tier (CPU local DRAM) ID stable (for example
> > > make it always 128)? That provides an anchor for users to understand.
> >
> > One of the motivations of introducing "rank" is to allow memory tier
> > ID to be stable, at least for the well-defined tiers such as the
> > default memory tier. The default memory tier can be moved around in
> > the tier hierarchy by adjusting its rank position relative to other
> > tiers, but its device ID can remain the same, e.g. always 1.
> >
>
> With /sys/devices/system/memtier/default_tier userspace will be able query
> the default tier details.
>

Yes. This is a way to address the memory tier ID stability issue too.
Anther choice is to make default_tier a symbolic link.


Best Regards,
Huang, Ying

\
 
 \ /
  Last update: 2022-06-16 07:52    [W:0.149 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site