lkml.org 
[lkml]   [2022]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: RFC: Memory Tiering Kernel Interfaces (v2)
On Thu, May 12, 2022 at 2:13 PM Tim Chen <tim.c.chen@linux.intel.com> wrote:
>
> On Thu, 2022-05-12 at 01:15 -0700, Wei Xu wrote:
> >
> > I am OK with moving back the memory tier nodelist into node/. When
> > there are more memory tier attributes needed, we can then create the
> > memory tier subtree and replace the tier nodelist in node/ with
> > symlinks.
> >
> > So the revised sysfs interfaces are:
> >
> > * /sys/devices/system/node/memory_tierN (read-only)
> >
> > where N = 0, 1, 2
> >
> > Format: node_list
> >
> > * /sys/devices/system/node/nodeN/memory_tier (read/write)
> >
> > where N = 0, 1, ...
> >
> > Format: int or empty
>
> This looks good to me. Just wonder if having just 1 tier
> lower than DRAM is sufficient. We could have wide performance
> range for such secondary memories and is one tier sufficient for them?
>
> Tim

The tier design can be extended to more than 3 tiers (e.g. via
CONFIG_MAX_MEMORY_TIERS). MAX_MEMORY_TIERS is set to 3 for now
because without enough memory device performance information provided
by the firmware, it is difficult for the kernel to properly initialize
the memory tier hierarchy beyond 3 tiers (GPU, DRAM, PMEM). We will
have to resort to the userspace override to set up such many-tier
systems.

\
 
 \ /
  Last update: 2022-05-12 23:33    [W:0.103 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site