[PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Lorenzo Stoakes]

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

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[David Hildenbrand (Arm)]

On 6/19/26 13:28, Lorenzo Stoakes wrote:
> 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>
> ---

Thanks!

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Pedro Falcato]

On Fri, Jun 19, 2026 at 12:28:51PM +0100, Lorenzo Stoakes wrote:
> 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>

Reviewed-by: Pedro Falcato <pfalcato@suse.de>

-- 
Pedro

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Matthew Wilcox]

On Fri, Jun 19, 2026 at 12:28:51PM +0100, Lorenzo Stoakes wrote:
> 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>

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Andrew Morton]

On Fri, 19 Jun 2026 12:28:51 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:

> 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.

I'm a little conflicted here.

7b32f64bc512 avoided readahead of "file pages outside the mapped
region", which is clearly desirable (arguably a bug fix?) and we care
about performance of executable mappings.  Whereas it isn't clear that
we care about whatever the heck that test case was doing.

IOW, the revert might make the kernel worse, overall.

If someone plans to get down and analyse that test case then come up
with a new version of 7b32f64bc512 then OK.  Is there such a person?

I'll park the revert in mm-unstable for now, but would prefer not to
rush it in until we better understand what's going on with that test
case and what can be done to address it.

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Matthew Wilcox]

On Fri, Jun 19, 2026 at 09:37:11AM -0700, Andrew Morton wrote:
> On Fri, 19 Jun 2026 12:28:51 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
> 
> > 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.
> 
> I'm a little conflicted here.
> 
> 7b32f64bc512 avoided readahead of "file pages outside the mapped
> region", which is clearly desirable (arguably a bug fix?) and we care
> about performance of executable mappings.  Whereas it isn't clear that
> we care about whatever the heck that test case was doing.
> 
> IOW, the revert might make the kernel worse, overall.
> 
> If someone plans to get down and analyse that test case then come up
> with a new version of 7b32f64bc512 then OK.  Is there such a person?
> 
> I'll park the revert in mm-unstable for now, but would prefer not to
> rush it in until we better understand what's going on with that test
> case and what can be done to address it.

Suren did that work.
https://lore.kernel.org/linux-mm/CAJuCfpH_Fp=J-m-kVZ3VVmqH0cAfNX6CQKWt3XmAJq1Rp9sFwQ@mail.gmail.com/

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Lorenzo Stoakes]

+cc Suren, Pedro, David - I messed up the cc on this patch.

On Fri, Jun 19, 2026 at 05:52:38PM +0100, Matthew Wilcox wrote:
> On Fri, Jun 19, 2026 at 09:37:11AM -0700, Andrew Morton wrote:
> > On Fri, 19 Jun 2026 12:28:51 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > > 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.
> >
> > I'm a little conflicted here.
> >
> > 7b32f64bc512 avoided readahead of "file pages outside the mapped
> > region", which is clearly desirable (arguably a bug fix?) and we care

I wouldn't say it's a bug fix? The kernel has always done this with no reported
bugs.

> > about performance of executable mappings.  Whereas it isn't clear that
> > we care about whatever the heck that test case was doing.
> >
> > IOW, the revert might make the kernel worse, overall.
> >
> > If someone plans to get down and analyse that test case then come up
> > with a new version of 7b32f64bc512 then OK.  Is there such a person?
> >
> > I'll park the revert in mm-unstable for now, but would prefer not to
> > rush it in until we better understand what's going on with that test
> > case and what can be done to address it.

As Willy points out [0], we've identified that it's a real usecase that we're
regressing.

There's likely others too in the real world.

This approach has also not been without debate in the past (see [1]), I think
this patch slipped under the radar on that front a bit.

So yeah, this does not to be reverted, and as a hotfix sooner rather than later.

>
> Suren did that work.
> https://lore.kernel.org/linux-mm/CAJuCfpH_Fp=J-m-kVZ3VVmqH0cAfNX6CQKWt3XmAJq1Rp9sFwQ@mail.gmail.com/

Thanks for highlighting that Willy (copied -> [0]).

Overall, if a patch causes a major regression in a core mm subsystem, people can
wait a cycle to re-evaluate.

Thanks, Lorenzo

[0]:https://lore.kernel.org/linux-mm/CAJuCfpH_Fp=J-m-kVZ3VVmqH0cAfNX6CQKWt3XmAJq1Rp9sFwQ@mail.gmail.com/
[1]:https://lore.kernel.org/linux-mm/CAC_TJvfG8GcwG_2w1o6GOTZS8tfEx2h9A91qsenYfYsX8Te=Bg@mail.gmail.com/

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Lorenzo Stoakes]

On Fri, Jun 19, 2026 at 06:07:35PM +0100, Lorenzo Stoakes wrote:
> So yeah, this does not to be reverted, and as a hotfix sooner rather than later.

Does _need_ to be reverted :)

What an unfortunate typo... :P

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Pedro Falcato]

On Fri, Jun 19, 2026 at 06:07:30PM +0100, Lorenzo Stoakes wrote:
> +cc Suren, Pedro, David - I messed up the cc on this patch.
> 
> On Fri, Jun 19, 2026 at 05:52:38PM +0100, Matthew Wilcox wrote:
> > On Fri, Jun 19, 2026 at 09:37:11AM -0700, Andrew Morton wrote:
> > > On Fri, 19 Jun 2026 12:28:51 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
> > >
> > > > 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.
> > >
> > > I'm a little conflicted here.
> > >
> > > 7b32f64bc512 avoided readahead of "file pages outside the mapped
> > > region", which is clearly desirable (arguably a bug fix?) and we care
> 
> I wouldn't say it's a bug fix? The kernel has always done this with no reported
> bugs.
> 
> > > about performance of executable mappings.  Whereas it isn't clear that
> > > we care about whatever the heck that test case was doing.
> > >
> > > IOW, the revert might make the kernel worse, overall.
> > >
> > > If someone plans to get down and analyse that test case then come up
> > > with a new version of 7b32f64bc512 then OK.  Is there such a person?
> > >
> > > I'll park the revert in mm-unstable for now, but would prefer not to
> > > rush it in until we better understand what's going on with that test
> > > case and what can be done to address it.
> 
> As Willy points out [0], we've identified that it's a real usecase that we're
> regressing.
> 
> There's likely others too in the real world.

Yeah, the mmap usage on SVT-AV1 is a little suspicious, but I guess the
pattern may come up time and time again for people doing chunked mmap
reads. I think we need to take a closer look at this change.
> 
> This approach has also not been without debate in the past (see [1]), I think
> this patch slipped under the radar on that front a bit.

Yeah, sadly it seems like the patch _may_ need a rather substantial rework :|
So I would err on the side of caution for now and revert it as well.

-- 
Pedro

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Suren Baghdasaryan]

On Fri, Jun 19, 2026 at 10:18 AM Pedro Falcato <pfalcato@suse.de> wrote:
>
> On Fri, Jun 19, 2026 at 06:07:30PM +0100, Lorenzo Stoakes wrote:
> > +cc Suren, Pedro, David - I messed up the cc on this patch.
> >
> > On Fri, Jun 19, 2026 at 05:52:38PM +0100, Matthew Wilcox wrote:
> > > On Fri, Jun 19, 2026 at 09:37:11AM -0700, Andrew Morton wrote:
> > > > On Fri, 19 Jun 2026 12:28:51 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
> > > >
> > > > > 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.
> > > >
> > > > I'm a little conflicted here.
> > > >
> > > > 7b32f64bc512 avoided readahead of "file pages outside the mapped
> > > > region", which is clearly desirable (arguably a bug fix?) and we care
> >
> > I wouldn't say it's a bug fix? The kernel has always done this with no reported
> > bugs.
> >
> > > > about performance of executable mappings.  Whereas it isn't clear that
> > > > we care about whatever the heck that test case was doing.
> > > >
> > > > IOW, the revert might make the kernel worse, overall.
> > > >
> > > > If someone plans to get down and analyse that test case then come up
> > > > with a new version of 7b32f64bc512 then OK.  Is there such a person?
> > > >
> > > > I'll park the revert in mm-unstable for now, but would prefer not to
> > > > rush it in until we better understand what's going on with that test
> > > > case and what can be done to address it.
> >
> > As Willy points out [0], we've identified that it's a real usecase that we're
> > regressing.
> >
> > There's likely others too in the real world.
>
> Yeah, the mmap usage on SVT-AV1 is a little suspicious, but I guess the
> pattern may come up time and time again for people doing chunked mmap
> reads. I think we need to take a closer look at this change.

Frame-by-frame mmapping for a streaming workoad is quite questionable
IMHO and I don't think we should be optimizing or encouraging such
usage, but I understand the reasoning for the revert.

> >
> > This approach has also not been without debate in the past (see [1]), I think
> > this patch slipped under the radar on that front a bit.
>
> Yeah, sadly it seems like the patch _may_ need a rather substantial rework :|
> So I would err on the side of caution for now and revert it as well.
>
> --
> Pedro

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Matthew Wilcox]

On Fri, Jun 19, 2026 at 10:43:06AM -0700, Suren Baghdasaryan wrote:
> > Yeah, the mmap usage on SVT-AV1 is a little suspicious, but I guess the
> > pattern may come up time and time again for people doing chunked mmap
> > reads. I think we need to take a closer look at this change.
> 
> Frame-by-frame mmapping for a streaming workoad is quite questionable
> IMHO and I don't think we should be optimizing or encouraging such
> usage, but I understand the reasoning for the revert.

If userspace is properly tuned, it doesn't need automatic readahead
at all; it can disable it and issue manual readaheads.  The point of
automatic readahead is to cope with userspace which is doing stupid
things like calling read() for a single byte at a time.

Could it have better defaults?  Maybe!  It's worth a try.  But those
attempts need to have a very low bar for reversion when it turns out
they affect other workloads.

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Suren Baghdasaryan]

On Fri, Jun 19, 2026 at 10:46 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Jun 19, 2026 at 10:43:06AM -0700, Suren Baghdasaryan wrote:
> > > Yeah, the mmap usage on SVT-AV1 is a little suspicious, but I guess the
> > > pattern may come up time and time again for people doing chunked mmap
> > > reads. I think we need to take a closer look at this change.
> >
> > Frame-by-frame mmapping for a streaming workoad is quite questionable
> > IMHO and I don't think we should be optimizing or encouraging such
> > usage, but I understand the reasoning for the revert.
>
> If userspace is properly tuned, it doesn't need automatic readahead
> at all; it can disable it and issue manual readaheads.  The point of
> automatic readahead is to cope with userspace which is doing stupid
> things like calling read() for a single byte at a time.
>
> Could it have better defaults?  Maybe!  It's worth a try.  But those
> attempts need to have a very low bar for reversion when it turns out
> they affect other workloads.

That what I meant in the last part of my reply :)

But in general, I think that benchmark measuring "how many frames per
second a CPU can encode" should be revised so it doesn't depend on
file prefetching mechanisms. Otherwise it's measuring something else.

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Pedro Falcato]

On Fri, Jun 19, 2026 at 10:52:07AM -0700, Suren Baghdasaryan wrote:
> On Fri, Jun 19, 2026 at 10:46 AM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Fri, Jun 19, 2026 at 10:43:06AM -0700, Suren Baghdasaryan wrote:
> > > > Yeah, the mmap usage on SVT-AV1 is a little suspicious, but I guess the
> > > > pattern may come up time and time again for people doing chunked mmap
> > > > reads. I think we need to take a closer look at this change.
> > >
> > > Frame-by-frame mmapping for a streaming workoad is quite questionable
> > > IMHO and I don't think we should be optimizing or encouraging such
> > > usage, but I understand the reasoning for the revert.
> >
> > If userspace is properly tuned, it doesn't need automatic readahead
> > at all; it can disable it and issue manual readaheads.  The point of
> > automatic readahead is to cope with userspace which is doing stupid
> > things like calling read() for a single byte at a time.
> >
> > Could it have better defaults?  Maybe!  It's worth a try.  But those
> > attempts need to have a very low bar for reversion when it turns out
> > they affect other workloads.
> 
> That what I meant in the last part of my reply :)
> 
> But in general, I think that benchmark measuring "how many frames per
> second a CPU can encode" should be revised so it doesn't depend on
> file prefetching mechanisms. Otherwise it's measuring something else.

To be clear, that's not (necessarily) a benchmark, the code we were
looking at is their encoder app.

(it's also generally not possible to prefetch the whole thing into RAM
because, well, raw video files are quite large)

-- 
Pedro

Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Suren Baghdasaryan]

On Fri, Jun 19, 2026 at 12:26 PM Pedro Falcato <pfalcato@suse.de> wrote:
>
> On Fri, Jun 19, 2026 at 10:52:07AM -0700, Suren Baghdasaryan wrote:
> > On Fri, Jun 19, 2026 at 10:46 AM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Fri, Jun 19, 2026 at 10:43:06AM -0700, Suren Baghdasaryan wrote:
> > > > > Yeah, the mmap usage on SVT-AV1 is a little suspicious, but I guess the
> > > > > pattern may come up time and time again for people doing chunked mmap
> > > > > reads. I think we need to take a closer look at this change.
> > > >
> > > > Frame-by-frame mmapping for a streaming workoad is quite questionable
> > > > IMHO and I don't think we should be optimizing or encouraging such
> > > > usage, but I understand the reasoning for the revert.
> > >
> > > If userspace is properly tuned, it doesn't need automatic readahead
> > > at all; it can disable it and issue manual readaheads.  The point of
> > > automatic readahead is to cope with userspace which is doing stupid
> > > things like calling read() for a single byte at a time.
> > >
> > > Could it have better defaults?  Maybe!  It's worth a try.  But those
> > > attempts need to have a very low bar for reversion when it turns out
> > > they affect other workloads.
> >
> > That what I meant in the last part of my reply :)
> >
> > But in general, I think that benchmark measuring "how many frames per
> > second a CPU can encode" should be revised so it doesn't depend on
> > file prefetching mechanisms. Otherwise it's measuring something else.
>
> To be clear, that's not (necessarily) a benchmark, the code we were
> looking at is their encoder app.

Ack.

>
> (it's also generally not possible to prefetch the whole thing into RAM
> because, well, raw video files are quite large)

For such streaminig workload I think read() would be more appropriate,
and the change limiting read-ahead by VMA size would not affect it.

>
> --
> Pedro