linux-kernel - Re: [PATCH RFC v3] mm: memory-tiering: Fix PGPROMOTE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87v7ng3hbv.fsf@DESKTOP-5N7EMDA>
Date: Fri, 25 Jul 2025 14:39:00 +0800
From: "Huang, Ying" <ying.huang@...ux.alibaba.com>
To: Shiyang Ruan <ruansy.fnst@...itsu.com>
Cc: linux-mm@...ck.org,  linux-kernel@...r.kernel.org,  lkp@...el.com,
  akpm@...ux-foundation.org,  y-goto@...itsu.com,  mingo@...hat.com,
  peterz@...radead.org,  juri.lelli@...hat.com,
  vincent.guittot@...aro.org,  dietmar.eggemann@....com,
  rostedt@...dmis.org,  mgorman@...e.de,  vschneid@...hat.com,  Li Zhijian
 <lizhijian@...itsu.com>,  Ben Segall <bsegall@...gle.com>
Subject: Re: [PATCH RFC v3] mm: memory-tiering: Fix PGPROMOTE_CANDIDATE
 counting

Shiyang Ruan <ruansy.fnst@...itsu.com> writes:

> 在 2025/7/24 15:36, Huang, Ying 写道:
>> Shiyang Ruan <ruansy.fnst@...itsu.com> writes:
>> 
>>> 在 2025/7/23 11:09, Huang, Ying 写道:
>>>> Ruan Shiyang <ruansy.fnst@...itsu.com> writes:
>>>>
>>>>> From: Li Zhijian <lizhijian@...itsu.com>
>>>>>
>>>>> ===
>>>>> Changes since v2:
>>>>>     1. According to Huang's suggestion, add a new stat to not count these
>>>>>     pages into PGPROMOTE_CANDIDATE, to avoid changing the rate limit
>>>>>     mechanism.
>>>>> ===
>>>> This isn't the popular place for changelog, please refer to other
>>>> patch
>>>> email.
>>>
>>> OK. I'll move this part down below.>
>>>>> Goto-san reported confusing pgpromote statistics where the
>>>>> pgpromote_success count significantly exceeded pgpromote_candidate.
>>>>>
>>>>> On a system with three nodes (nodes 0-1: DRAM 4GB, node 2: NVDIMM 4GB):
>>>>>    # Enable demotion only
>>>>>    echo 1 > /sys/kernel/mm/numa/demotion_enabled
>>>>>    numactl -m 0-1 memhog -r200 3500M >/dev/null &
>>>>>    pid=$!
>>>>>    sleep 2
>>>>>    numactl memhog -r100 2500M >/dev/null &
>>>>>    sleep 10
>>>>>    kill -9 $pid # terminate the 1st memhog
>>>>>    # Enable promotion
>>>>>    echo 2 > /proc/sys/kernel/numa_balancing
>>>>>
>>>>> After a few seconds, we observeed `pgpromote_candidate < pgpromote_success`
>>>>> $ grep -e pgpromote /proc/vmstat
>>>>> pgpromote_success 2579
>>>>> pgpromote_candidate 0
>>>>>
>>>>> In this scenario, after terminating the first memhog, the conditions for
>>>>> pgdat_free_space_enough() are quickly met, and triggers promotion.
>>>>> However, these migrated pages are only counted for in PGPROMOTE_SUCCESS,
>>>>> not in PGPROMOTE_CANDIDATE.
>>>>>
>>>>> To solve this confusing statistics, introduce this
>>>>> PGPROMOTE_CANDIDATE_NOLIMIT to count the missed promotion pages.  And
>>>>> also, not counting these pages into PGPROMOTE_CANDIDATE is to avoid
>>>>> changing the existing algorithm or performance of the promotion rate
>>>>> limit.
>>>>>
>>>>> Perhaps PGPROMOTE_CANDIDATE_NOLIMIT is not well named, please comment if
>>>>> you have a better idea.
>>>> Yes.  Naming is hard.  I guess that the name comes from the
>>>> promotion
>>>> that isn't rate limited.  I have asked Deepseek that what is the good
>>>> abbreviation for "not rate limited".  Its answer is "NRL".  I don't know
>>>> whether it's good.  However, "NOT_RATE_LIMITED" appears too long.
>>>
>>> "NRL" Sounds good to me.
>>>
>>> I'm thinking another one: since it's not rate limited, it could be
>>> migrated quickly/fast.  How about PGPROMOTE_CANDIDATE_FAST?
>> This sounds good to me, Thanks!
>
> Gemini 2.5 gave me a more radical name for it:
>
> /*
>  * Candidate pages for promotion based on hint fault latency. This counter
>  * is used by the feedback mechanism to control the promotion rate and
>  * adjust the hot threshold.
>  */
> PGPROMOTE_CANDIDATE,
> /*
>  * Pages promoted aggressively to a fast-tier node when it has sufficient
>  * free space. These promotions bypass the regular hotness checks and do
>  * NOT influence the promotion rate-limiter or threshold-adjustment logic.
>  * This is for statistics/monitoring purposes.
>  */
> PGPROMOTED_AGGRESSIVE,
>
> I think this one is concise and easy to understand with the
> comments. What do you think?  If this one is not appropriate, then I
> will go with "_NRL" as you suggested.

In fact, we still count candidate pages here.  Although there's enough
free space in the target node, the promotion may still fail for say
increased refcount.

---
Best Regards,
Huang, Ying

[snip]