From: Lorenzo Stoakes <ljs@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Frederick Mayle <fmayle@google.com>,
Kalesh Singh <kaleshsingh@google.com>,
Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"
Date: Fri, 19 Jun 2026 12:28:51 +0100 [thread overview]
Message-ID: <20260619112852.104213-1-ljs@kernel.org> (raw)
This reverts commit 7b32f64bc512b40b268776c5ac4d354b325b3197.
This patch caused a significant performance regression, so revert it, and
we can determine whether the approach is sensible or not moving forwards,
and if so how to avoid this.
There was a merge conflict with commit de97ae6222c1 ("mm/readahead: no
PG_readahead on EOF"), care was taken to ensure that the revert retained the
behaviour of this patch and cleanly reverts commit 7b32f64bc512 ("mm: limit
filemap_fault readahead to VMA boundaries") only.
Fixes: 7b32f64bc512 ("mm: limit filemap_fault readahead to VMA boundaries")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202606181547.617a6967-lkp@intel.com
Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
---
include/linux/pagemap.h | 2 --
mm/filemap.c | 4 ----
mm/readahead.c | 6 +-----
3 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 627771e82eb1..2c3718d592d6 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -1348,7 +1348,6 @@ struct readahead_control {
struct file_ra_state *ra;
/* private: use the readahead_* accessors instead */
pgoff_t _index;
- pgoff_t _max_index; /* limit readahead to _max_index, inclusive */
unsigned int _nr_pages;
unsigned int _batch_count;
bool dropbehind;
@@ -1362,7 +1361,6 @@ struct readahead_control {
.mapping = m, \
.ra = r, \
._index = i, \
- ._max_index = ULONG_MAX, \
}
#define VM_READAHEAD_PAGES (SZ_128K / PAGE_SIZE)
diff --git a/mm/filemap.c b/mm/filemap.c
index dc3a0e960b9f..17a64837597c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3312,8 +3312,6 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
unsigned int thp_order = 0;
unsigned short mmap_miss;
- ractl._max_index = vmf->vma->vm_pgoff + vma_pages(vmf->vma) - 1;
-
/* Use the readahead code, even if readahead is disabled */
if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && (vm_flags & VM_HUGEPAGE)) {
/*
@@ -3409,7 +3407,6 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
* mmap read-around
*/
ra->start = max_t(long, 0, vmf->pgoff - ra->ra_pages / 2);
- ra->start = max(ra->start, vmf->vma->vm_pgoff);
ra->size = ra->ra_pages;
ra->async_size = ra->ra_pages / 4;
ra->order = 0;
@@ -3457,7 +3454,6 @@ static struct file *do_async_mmap_readahead(struct vm_fault *vmf,
}
if (folio_test_readahead(folio)) {
- ractl._max_index = vmf->vma->vm_pgoff + vma_pages(vmf->vma) - 1;
fpin = maybe_unlock_mmap_for_io(vmf, fpin);
page_cache_async_ra(&ractl, folio, ra->ra_pages);
}
diff --git a/mm/readahead.c b/mm/readahead.c
index 38ce16e3fcbd..558c92957518 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -335,8 +335,6 @@ static void do_page_cache_ra(struct readahead_control *ractl,
return;
end_index = (isize - 1) >> PAGE_SHIFT;
- if (end_index > ractl->_max_index)
- end_index = ractl->_max_index;
if (index > end_index)
return;
/* Don't read past the page containing the last byte of the file */
@@ -487,7 +485,7 @@ void page_cache_ra_order(struct readahead_control *ractl,
pgoff_t start = readahead_index(ractl);
pgoff_t index = start;
unsigned int min_order = mapping_min_folio_order(mapping);
- pgoff_t limit;
+ pgoff_t limit = (i_size_read(mapping->host) - 1) >> PAGE_SHIFT;
pgoff_t mark;
unsigned int nofs;
int err = 0;
@@ -500,8 +498,6 @@ void page_cache_ra_order(struct readahead_control *ractl,
goto fallback;
}
- limit = (i_size_read(mapping->host) - 1) >> PAGE_SHIFT;
- limit = min(limit, ractl->_max_index);
if (limit > index + ra->size - 1) {
limit = index + ra->size - 1;
mark = index + ra->size - ra->async_size;
--
2.54.0
next reply other threads:[~2026-06-19 11:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 11:28 Lorenzo Stoakes [this message]
2026-06-19 11:40 ` [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries" David Hildenbrand (Arm)
2026-06-19 11:58 ` Pedro Falcato
2026-06-19 15:47 ` Matthew Wilcox
2026-06-19 16:37 ` Andrew Morton
2026-06-19 16:52 ` Matthew Wilcox
2026-06-19 17:07 ` Lorenzo Stoakes
2026-06-19 17:08 ` Lorenzo Stoakes
2026-06-19 17:18 ` Pedro Falcato
2026-06-19 17:43 ` Suren Baghdasaryan
2026-06-19 17:46 ` Matthew Wilcox
2026-06-19 17:52 ` Suren Baghdasaryan
2026-06-19 19:26 ` Pedro Falcato
2026-06-19 19:33 ` Suren Baghdasaryan
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=20260619112852.104213-1-ljs@kernel.org \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=fmayle@google.com \
--cc=jack@suse.cz \
--cc=kaleshsingh@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/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