[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aWGTNfrLBhCM3_-9@google.com>
Date: Fri, 9 Jan 2026 23:45:57 +0000
From: Bing Jiao <bingjiao@...gle.com>
To: Donet Tom <donettom@...ux.ibm.com>
Cc: linux-mm@...ck.org, 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 Thu, Jan 08, 2026 at 06:14:02PM +0530, Donet Tom wrote:
>
> On 1/7/26 12:58 PM, Bing Jiao wrote:
> > + /* 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?
Hi Donet,
Thanks for your questions.
Yes, the random selection could select a distant node and lead to
incresed promotion latency.
I just realized that the the fallback allocation should not weighted
by a single metric, such as node distance, capacity, free space.
We need a thoroughly study before changing alloc_demote_folio().
Best,
Bing
Powered by blists - more mailing lists