Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2023-03-03 at 03:49 +0000, Matthew Wilcox wrote:
> On Thu, Mar 02, 2023 at 06:58:58PM -0700, Keith Busch wrote:
> > That said, I was hoping you were going to suggest supporting 16k
> > logical block sizes. Not a problem on some arch's, but still
> > problematic when PAGE_SIZE is 4k. :)
> 
> I was hoping Luis was going to propose a session on LBA size >
> PAGE_SIZE. Funnily, while the pressure is coming from the storage
> vendors, I don't think there's any work to be done in the storage
> layers.  It's purely a FS+MM problem.

Heh, I can do the fools rush in bit, especially if what we're
interested in the minimum it would take to support this ...

The FS problem could be solved simply by saying FS block size must
equal device block size, then it becomes purely a MM issue.  The MM
issue could be solved by adding a page order attribute to struct
address_space and insisting that pagecache/filemap functions in
mm/filemap.c all have to operate on objects that are an integer
multiple of the address space order.  The base allocator is
filemap_alloc_folio, which already has an apparently always zero order
parameter (hmmm...) and it always seems to be called from sites that
have the address_space, so it could simply be modified to always
operate at the address_space order.

The above would be a bit suboptimal in that blocks are always mapped to
physically contiguous pages, but it should be enough to get the concept
working.

James