[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87zfe220o7.fsf@DESKTOP-5N7EMDA>
Date: Fri, 20 Jun 2025 17:59:52 +0800
From: "Huang, Ying" <ying.huang@...ux.alibaba.com>
To: Bharata B Rao <bharata@....com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Jonathan.Cameron@...wei.com, dave.hansen@...el.com, gourry@...rry.net,
hannes@...xchg.org, mgorman@...hsingularity.net, mingo@...hat.com,
peterz@...radead.org, raghavendra.kt@....com, riel@...riel.com,
rientjes@...gle.com, sj@...nel.org, weixugc@...gle.com,
willy@...radead.org, ziy@...dia.com, dave@...olabs.net,
nifan.cxl@...il.com, xuezhengchu@...wei.com, yiannis@...corp.com,
akpm@...ux-foundation.org, david@...hat.com
Subject: Re: [RFC PATCH v1 0/4] Kernel thread based async batch migration
Bharata B Rao <bharata@....com> writes:
> On 20-Jun-25 12:09 PM, Huang, Ying wrote:
>> Bharata B Rao <bharata@....com> writes:
>> <snip>
>>
>> I don't think page flag + scanning is a good idea.If the
>
> If extended page flags is not the ideal location (I chose it in this
> version only to get something going quickly), we can look at maintaining
> per-pfn allocation for the required hot page metadata separately.
>
> Or is your concern specifically with scanning? What problems do you
> see?
>
> It is the cost or the possibility of not identifying the migrate-ready
> pages in time? Or something else??
We may need to scan a large number of pages to identify a page to
promote. This will waste CPU cycles and pollute cache.
---
Best Regards,
Huang, Ying
Powered by blists - more mailing lists