Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Optimizing Page Cache Readahead Behavior

[Dave Chinner <david@fromorbit.com>]

On Thu, Feb 27, 2025 at 10:12:50PM +0000, Matthew Wilcox wrote:
> On Tue, Feb 25, 2025 at 10:56:21AM +1100, Dave Chinner wrote:
> > > From the previous discussions that Matthew shared [7], it seems like
> > > Dave proposed an alternative to moving the extents to the VFS layer to
> > > invert the IO read path operations [8]. Maybe this is a move
> > > approachable solution since there is precedence for the same in the
> > > write path?
> > > 
> > > [7] https://lore.kernel.org/linux-fsdevel/Zs97qHI-wA1a53Mm@casper.infradead.org/
> > > [8] https://lore.kernel.org/linux-fsdevel/ZtAPsMcc3IC1VaAF@dread.disaster.area/
> > 
> > Yes, if we are going to optimise away redundant zeros being stored
> > in the page cache over holes, we need to know where the holes in the
> > file are before the page cache is populated.
> 
> Well, you shot that down when I started trying to flesh it out:
> https://lore.kernel.org/linux-fsdevel/Zs+2u3%2FUsoaUHuid@dread.disaster.area/

No, I shot down the idea of having the page cache maintain a generic
cache of file offset to LBA address mappings outside the filesystem.

Having the filesystem insert a special 'this is a hole' entry into
the mapping tree insert of allocating and inserting a page full of
zeroes is not an extent cache - it's just a different way of
representing a data range that is known to always contain zeroes.

> > As for efficient hole tracking in the mapping tree, I suspect that
> > we should be looking at using exceptional entries in the mapping
> > tree for holes, not inserting mulitple references to the zero folio.
> > i.e. the important information for data storage optimisation is that
> > the region covers a hole, not that it contains zeros.
> 
> The xarray is very much optimised for storing power-of-two sized &
> aligned objects.  It makes no sense to try to track extents using the
> mapping tree.

Certainly. I'm not suggesting that we do this at all, and ....

> Now, if we abandon the radix tree for the maple tree, we
> could talk about storing zero extents in the same data structure.
> But that's a big change with potentially significant downsides.
> It's something I want to play with, but I'm a little busy right now.

.... I still do not want the page cache to try to maintain a block
mapping/extent cache in addition to the what the filesystem must
already maintain for the reasons I have previously given.

> > For buffered reads, all that is required when such an exceptional
> > entry is returned is a memset of the user buffer. For buffered
> > writes, we simply treat it like a normal folio allocating write and
> > replace the exceptional entry with the allocated (and zeroed) folio.
> 
> ... and unmap the zero page from any mappings.

Sure. That's just a call to unmap_mapping_range(), yes?

> > For read page faults, the zero page gets mapped (and maybe
> > accounted) via the vma rather than the mapping tree entry. For write
> > faults, a folio gets allocated and the exception entry replaced
> > before we call into ->page_mkwrite().
> > 
> > Invalidation simply removes the exceptional entries.
> 
> ... and unmap the zero page from any mappings.

Invalidation already calls unmap_mapping_range(), so this should
already be handled, right?

-Dave.
-- 
Dave Chinner
david@fromorbit.com