linux-kernel - Re: [PATCH v1 1/2] mm/vmscan: balance demotion allocation in alloc_demote

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <761533a9-b188-43b1-a24a-1893622ce18c@linux.ibm.com>
Date: Thu, 8 Jan 2026 18:14:02 +0530
From: Donet Tom <donettom@...ux.ibm.com>
To: Bing Jiao <bingjiao@...gle.com>, linux-mm@...ck.org
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        David Hildenbrand <david@...nel.org>, Michal Hocko <mhocko@...nel.org>,
        Qi Zheng <zhengqi.arch@...edance.com>,
        Shakeel Butt <shakeel.butt@...ux.dev>,
        Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/2] mm/vmscan: balance demotion allocation in
 alloc_demote_folio()


On 1/7/26 12:58 PM, Bing Jiao wrote:
> When the preferred demotion node does not have enough free space,
> alloc_demote_folio() attempts to allocate from fallback nodes.
> Currently, it lacks a mechanism to distribute these fallback allocations,
> which can lead to unbalanced memory pressure across fallback nodes.
>
> Balance the allocation by randomly selecting a new preferred node from
> the fallback nodes if the initial allocation from the old preferred
> node fails.
>
> Signed-off-by: Bing Jiao <bingjiao@...gle.com>
> ---
>   mm/vmscan.c | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 81828fa625ed..db2413c4bd26 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1009,6 +1009,11 @@ static struct folio *alloc_demote_folio(struct folio *src,
>   	if (dst)
>   		return dst;
>
> +	/* Randomly select a node from fallback nodes for balanced allocation */
> +	if (allowed_mask) {
> +		mtc->nid = node_random(allowed_mask);


This random selection can cause allocations to fall back to distant 
memory even when the nearer demotion target has sufficient free memory, 
correct? Could this also lead to increased promotion latency?


> +		node_clear(mtc->nid, *allowed_mask);
> +	}
>   	mtc->gfp_mask &= ~__GFP_THISNODE;
>   	mtc->nmask = allowed_mask;
>
> --
> 2.52.0.358.g0dd7633a29-goog
>
>