[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251027140315.907864-1-zhangqilong3@huawei.com>
Date: Mon, 27 Oct 2025 22:03:12 +0800
From: Zhang Qilong <zhangqilong3@...wei.com>
To: <akpm@...ux-foundation.org>, <david@...hat.com>,
<lorenzo.stoakes@...cle.com>, <Liam.Howlett@...cle.com>, <vbabka@...e.cz>,
<rppt@...nel.org>, <surenb@...gle.com>, <mhocko@...e.com>,
<jannh@...gle.com>, <pfalcato@...e.de>
CC: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
<wangkefeng.wang@...wei.com>, <sunnanyong@...wei.com>
Subject: [RFC PATCH 0/3] mm: PTEs batch optimization in mincore and mremap
This first patch extract a new interface named can_pte_batch_count()
from folio_pte_batch_flags() for pte batch. Thew new interface avoids
folio access, and counts more pte, not just limited to entries mapped
within a single folio. Caller need pass a range within a single VMA
and a single page and it detect consecutive (present) PTEs that map
consecutive pages. The 2th and 3rd patches use can_pte_batch_count()
do pte batch.
Zhang Qilong (3):
mm: Introduce can_pte_batch_count() for PTEs batch optimization.
mm/mincore: Use can_pte_batch_count() in mincore_pte_range() for pte
batch mincore_pte_range()
mm/mremap: Use can_pte_batch_count() instead of folio_pte_batch() for
pte batch
mm/internal.h | 76 +++++++++++++++++++++++++++++++++++++++------------
mm/mincore.c | 10 ++-----
mm/mremap.c | 16 ++---------
3 files changed, 64 insertions(+), 38 deletions(-)
--
2.43.0
Powered by blists - more mailing lists