Re: [RFC PATCH 13/18] mm/filemap: store the end of a read in f_ra only when it changes

[Kiryl Shutsemau <kas@kernel.org>]

On Tue, Oct 20, 2026 at 11:20:00AM -1000, Linus Torvalds wrote:
> On Mon, 19 Oct 2026 at 05:50, Kiryl Shutsemau (Meta) <kas@kernel.org> wrote:
> >
> > filemap_read() writes the end of every read to file->f_ra.prev_pos.
> > Threads that read through one open file all write that cache line, on
> > every read.  The value often stays the same, as for reads that start at
> > the same offset each time.
> 
> This seems silly. That "often stays the same" is only true for the
> pointless benchmark, no?
> 
> I don't think it's ever true in any real load.

Right. The patch is bogus, not only the commit message.

It is worse than useless: for random reads prev_pos changes every time,
so the compare reads the shared line and then writes it anyway.
Bisecting a RocksDB slowdown led here: with patches 1-12 it runs at base
speed, this one costs 4-5% at 16-64 threads.

The store itself does matter in a real load.  RocksDB threads pread()
through one fd per SST file, opened with POSIX_FADV_RANDOM.  With the
folio refcount gone, the prev_pos store on that shared struct file is
what they fight over next.

For an FMODE_RANDOM file nothing reads prev_pos but filemap_read()
itself: readahead is forced and returns before looking at it.  Skipping
the store there takes a small hot table at 64 threads from 10.7M to
14.1M Gets/s, against 12.5M with the series as posted.

I will replace this patch with that.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov