Re: [PATCH 4/9] xfs: kill XBF_UNMAPPED

[Dave Chinner <david@fromorbit.com>]

On Tue, Mar 19, 2024 at 10:30:46AM -0700, Darrick J. Wong wrote:
> On Tue, Mar 19, 2024 at 09:45:55AM +1100, Dave Chinner wrote:
> > From: Christoph Hellwig <hch@lst.de>
> > 
> > Unmapped buffer access is a pain, so kill it. The switch to large
> > folios means we rarely pay a vmap penalty for large buffers,
> > so this functionality is largely unnecessary now.
> 
> What was the original point of unmapped buffers?  Was it optimizing for
> not using vmalloc space for inode buffers on 32-bit machines?

Largely, yes. This is original XFS-on-Irix design details from the
early 1990s.

The Irix buffer cache could vmap multi-page buffers on demand, but
it could also ask the page allocator/page cache to use use 16kB or
64kB large pages for the buffers to avoid needing vmap. The Irix mm
subsystem was multi-page size aware even on 32 bit machines
(heterogenous, simultaneous use of 4kB, 16kB, 64kB, 256kB, 2MB, and
16MB page sizes within the page cache and the buffer cache was
supported). However, the kernel had a limited vmap pool size even
on 64 bit machines. Hence buffers tended to be mapped and unmapped
at access time similar to how we use kmap_*() on Linux.

As a result, base page size allocation was still always preferred,
so in the cases where vmap or larger pages were not actually
needed they were avoided via unmapped buffers.

It's definitely a positive for us that the linux mm is nearing
functional parity with Irix from the mid 1990s. It means we can
slowly remove the compromises the Linux XFS port had to make to
work on Linux.  If we can now just get GFP_NOFAIL as the the
official memory allocator policy....

> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> 
> Reviewed-by: Darrick J. Wong <djwong@kernel.org>

Thanks!

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