From: Chi Zhiling <chizhiling@163.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Cc: Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>, Zi Yan <ziy@nvidia.com>,
"Liam R. Howlett" <liam@infradead.org>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Chi Zhiling <chizhiling@kylinos.cn>
Subject: [PATCH v1 1/5] mm/filemap: reduce unnecessary xarray lookups when read cached pages
Date: Wed, 20 May 2026 18:15:34 +0800 [thread overview]
Message-ID: <20260520101538.58745-2-chizhiling@163.com> (raw)
In-Reply-To: <20260520101538.58745-1-chizhiling@163.com>
From: Chi Zhiling <chizhiling@kylinos.cn>
When reading small amounts of data from the page cache, only a single
folio is typically returned from filemap_read_get_batch(). In this case,
calling xas_advance() or xas_next() after adding the folio to the batch
is unnecessary and only introduces extra branches.
The same issue exists for large reads, where one additional xarray walk
is always performed before termination.
Move the boundary check to after the folio is added to the batch so the
final redundant xarray advancement can be avoided. This significantly
reduces the branch count in the read path.
xas_next() does not update xa_index when xas->xa_node is set to
XAS_RESTART, so checking the boundary before updating xa_index is
sufficient to keep the folio within range. The warning should therefore
never trigger.
The branch count:
654.198 M/sec -> 646.444 M/sec
Performance counter stats for 'fio --ioengine=sync --rw=read --bs=4k --size=1G
--runtime=300 --time_based --group_reporting --name=seq_read_test --filename=file':
before:
READ: bw=2697MiB/s (2828MB/s), 2697MiB/s-2697MiB/s (2828MB/s-2828MB/s), io=790GiB (848GB), run=300001-300001msec
245602051556 task-clock # 0.821 CPUs utilized
78467 context-switches # 319.488 /sec
40 cpu-migrations # 0.163 /sec
3388 page-faults # 13.795 /sec
758312319204 instructions # 0.74 insn per cycle
1025881497502 cycles # 4.177 GHz
160672383734 branches # 654.198 M/sec
361904512 branch-misses # 0.23% of all branches
after:
READ: bw=2709MiB/s (2841MB/s), 2709MiB/s-2709MiB/s (2841MB/s-2841MB/s), io=794GiB (852GB), run=300000-300000msec
243985503670 task-clock # 0.812 CPUs utilized
79004 context-switches # 323.806 /sec
30 cpu-migrations # 0.123 /sec
3355 page-faults # 13.751 /sec
747830935069 instructions # 0.73 insn per cycle
1019609333322 cycles # 4.179 GHz
157722976668 branches # 646.444 M/sec
348984893 branch-misses # 0.22% of all branches
Signed-off-by: Chi Zhiling <chizhiling@kylinos.cn>
---
mm/filemap.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 4e636647100c..d54450e529bd 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2458,12 +2458,16 @@ static void filemap_get_read_batch(struct address_space *mapping,
{
XA_STATE(xas, &mapping->i_pages, index);
struct folio *folio;
+ pgoff_t next;
+
+ if (unlikely(index > max))
+ return;
rcu_read_lock();
for (folio = xas_load(&xas); folio; folio = xas_next(&xas)) {
if (xas_retry(&xas, folio))
continue;
- if (xas.xa_index > max || xa_is_value(folio))
+ if (xa_is_value(folio) || WARN_ON(xas.xa_index > max))
break;
if (xa_is_sibling(folio))
break;
@@ -2479,7 +2483,11 @@ static void filemap_get_read_batch(struct address_space *mapping,
break;
if (folio_test_readahead(folio))
break;
- xas_advance(&xas, folio_next_index(folio) - 1);
+
+ next = folio_next_index(folio);
+ if (next > max)
+ break;
+ xas_advance(&xas, next - 1);
continue;
put_folio:
folio_put(folio);
--
2.43.0
next prev parent reply other threads:[~2026-05-20 10:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 10:15 [PATCH v1 0/5] mm/shmem: optimize read with reduced xarray lookups and folio batching Chi Zhiling
2026-05-20 10:15 ` Chi Zhiling [this message]
2026-05-20 10:15 ` [PATCH v1 2/5] mm/filemap: reduce xarray lookups in filemap_get_folios_contig() Chi Zhiling
2026-05-20 10:15 ` [PATCH v1 3/5] mm/shmem: make SGP_NOALLOC succeed on hole like SGP_READ Chi Zhiling
2026-05-25 7:10 ` Baolin Wang
2026-05-25 8:14 ` Chi Zhiling
2026-05-25 8:44 ` Baolin Wang
2026-05-20 10:15 ` [PATCH v1 4/5] mm/shmem: introduce copy_zero_to_iter() for large zeroing Chi Zhiling
2026-05-20 10:15 ` [PATCH v1 5/5] mm/shmem: optimize file read with folio batching Chi Zhiling
2026-05-25 8:37 ` Baolin Wang
2026-05-25 9:47 ` Chi Zhiling
2026-05-26 3:11 ` Baolin Wang
2026-05-26 7:12 ` Chi Zhiling
2026-06-01 11:20 ` Baolin Wang
2026-06-01 14:37 ` Chi Zhiling
2026-05-22 0:14 ` [PATCH v1 0/5] mm/shmem: optimize read with reduced xarray lookups and " Andrew Morton
2026-05-22 1:36 ` Chi Zhiling
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=20260520101538.58745-2-chizhiling@163.com \
--to=chizhiling@163.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=chizhiling@kylinos.cn \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=npache@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.org \
--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
Powered by JetHome