From: Karim Manaouil <kmanaouil.dev@gmail.com>
To: Zi Yan <ziy@nvidia.com>
Cc: David Hildenbrand <david@redhat.com>,
Bharata B Rao <bharata@amd.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Jonathan.Cameron@huawei.com, dave.hansen@intel.com,
gourry@gourry.net, hannes@cmpxchg.org,
mgorman@techsingularity.net, mingo@redhat.com,
peterz@infradead.org, raghavendra.kt@amd.com, riel@surriel.com,
rientjes@google.com, sj@kernel.org, weixugc@google.com,
willy@infradead.org, ying.huang@linux.alibaba.com,
dave@stgolabs.net, nifan.cxl@gmail.com, joshua.hahnjy@gmail.com,
xuezhengchu@huawei.com, yiannis@zptcorp.com,
akpm@linux-foundation.org
Subject: Re: [RFC PATCH v0 2/2] mm: sched: Batch-migrate misplaced pages
Date: Wed, 28 May 2025 13:25:13 +0100 [thread overview]
Message-ID: <20250528122513.4rxzkia7lge7du5p@ed.ac.uk> (raw)
In-Reply-To: <94BF4806-ABCD-4D01-8577-9E138A634815@nvidia.com>
On Mon, May 26, 2025 at 10:20:39AM -0400, Zi Yan wrote:
> On 26 May 2025, at 5:29, David Hildenbrand wrote:
> > PFN scanning can be faster than walking lists, but I suspect it depends on how many pages there really are to be migrated ... and some other factors :)
>
> Yes. LRU list is good since it restricts the scanning range, but PFN scanning
> itself does not have it. PFN scanning with some filter mechanism might work
> and that filter mechanism is a way of marking to-be-migrated pages. Of course,
> a quick re-evaluation of the to-be-migrated pages right before a migration
> would avoid unnecessary work like we discussed above.
PFN scanning could be faster because of prefetching, but it pollutes the
caches, which may not be nice to the application running on that cpu
core before we transitioned to kernel space.
--
~karim
next prev parent reply other threads:[~2025-05-28 12:25 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 8:02 [RFC PATCH v0 0/2] Batch migration for NUMA balancing Bharata B Rao
2025-05-21 8:02 ` [RFC PATCH v0 1/2] migrate: implement migrate_misplaced_folio_batch Bharata B Rao
2025-05-22 15:59 ` David Hildenbrand
2025-05-22 16:03 ` Gregory Price
2025-05-22 16:08 ` David Hildenbrand
2025-05-26 8:16 ` Huang, Ying
2025-05-21 8:02 ` [RFC PATCH v0 2/2] mm: sched: Batch-migrate misplaced pages Bharata B Rao
2025-05-21 18:25 ` Donet Tom
2025-05-21 18:40 ` Zi Yan
2025-05-22 3:24 ` Gregory Price
2025-05-22 5:23 ` Bharata B Rao
2025-05-22 4:42 ` Bharata B Rao
2025-05-22 4:39 ` Bharata B Rao
2025-05-23 9:05 ` Donet Tom
2025-05-22 3:55 ` Gregory Price
2025-05-22 7:33 ` Bharata B Rao
2025-05-22 15:38 ` Gregory Price
2025-05-22 16:11 ` David Hildenbrand
2025-05-22 16:24 ` Zi Yan
2025-05-22 16:26 ` David Hildenbrand
2025-05-22 16:38 ` Zi Yan
2025-05-22 17:21 ` David Hildenbrand
2025-05-22 17:30 ` Zi Yan
2025-05-26 8:33 ` Huang, Ying
2025-05-26 9:29 ` David Hildenbrand
2025-05-26 14:20 ` Zi Yan
2025-05-27 1:18 ` Huang, Ying
2025-05-27 1:27 ` Zi Yan
2025-05-28 12:25 ` Karim Manaouil [this message]
2025-05-26 5:14 ` Bharata B Rao
2025-05-21 18:45 ` [RFC PATCH v0 0/2] Batch migration for NUMA balancing SeongJae Park
2025-05-22 3:08 ` Gregory Price
2025-05-22 16:30 ` SeongJae Park
2025-05-22 17:40 ` Gregory Price
2025-05-22 18:52 ` SeongJae Park
2025-05-22 18:43 ` Apologies and clarifications on DAMON-disruptions (was Re: [RFC PATCH v0 0/2] Batch migration for NUMA balancing) SeongJae Park
2025-05-26 5:20 ` [RFC PATCH v0 0/2] Batch migration for NUMA balancing Bharata B Rao
2025-05-27 18:50 ` SeongJae Park
2025-05-26 8:46 ` Huang, Ying
2025-05-27 8:53 ` Bharata B Rao
2025-05-27 9:05 ` Huang, Ying
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250528122513.4rxzkia7lge7du5p@ed.ac.uk \
--to=kmanaouil.dev@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=bharata@amd.com \
--cc=dave.hansen@intel.com \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=nifan.cxl@gmail.com \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@amd.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=sj@kernel.org \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=xuezhengchu@huawei.com \
--cc=yiannis@zptcorp.com \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox