lkml.org 
[lkml]   [2022]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v5 1/9] mm/demotion: Add support for explicit memory tiers
From
On 6/8/22 10:12 PM, Yang Shi wrote:
> On Tue, Jun 7, 2022 at 9:58 PM Aneesh Kumar K V
> <aneesh.kumar@linux.ibm.com> wrote:

....

>> config TIERED_MEMORY
>> bool "Support for explicit memory tiers"
>> - def_bool n
>> - depends on MIGRATION && NUMA
>> - help
>> - Support to split nodes into memory tiers explicitly and
>> - to demote pages on reclaim to lower tiers. This option
>> - also exposes sysfs interface to read nodes available in
>> - specific tier and to move specific node among different
>> - possible tiers.
>> + def_bool MIGRATION && NUMA
>
> CONFIG_NUMA should be good enough. Memory tiering doesn't have to mean
> demotion/promotion has to be supported IMHO.
>
>>
>> config HUGETLB_PAGE_SIZE_VARIABLE
>> def_bool n
>>
>> ie, we just make it a Kconfig variable without exposing it to the user?
>>

We can do that but that would also mean in order to avoid building the
demotion targets etc we will now have to have multiple #ifdef
CONFIG_MIGRATION in mm/memory-tiers.c . It builds without those #ifdef
So these are not really build errors, but rather we will be building all
the demotion targets for no real use with them.

What usecase do you have to expose memory tiers on a system with
CONFIG_MIGRATION disabled? CONFIG_MIGRATION gets enabled in almost all
configs these days due to its dependency against COMPACTION and
TRANSPARENT_HUGEPAGE.

Unless there is a real need, I am wondering if we can avoid sprinkling
#ifdef CONFIG_MIGRATION in mm/memory-tiers.c

-aneesh

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