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@xxxxxx> > > > > 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@xxxxxx> > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> Thanks! -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
