Re: [PATCH v2] btrfs: don't limit direct reads to a single sector

[Christoph Hellwig <hch@lst.de>]

On Tue, Jun 21, 2022 at 02:55:06PM +0800, Qu Wenruo wrote:
> A little off-topic here, what did the extra XFS/iomap do here?
>
> IIRC the multi-page bio vector is already there for years.

Yes.

> As long as the pages in page cache are contiguous, bio_add_page() will 
> create such multi-page vector, without any extra support from fs.

Yes.  Every file system supports that case right now, but that only
covers the case where pages are contiguous by luck because the
allocations worked that way.  The iomap THP support is all about
having I/O map (and to a small extent the file system, which for now
is just xfs) to be able to deal with large folios, that is > PAGE_SIZE
compound allocations.

>>  At which point
>> allocating the larger csums array is also not a problem as we can
>> find contigous memory for that easily as well.  For direct I/O on the
>> other hand the destination could be THPs or hugetlbs even when memory
>> is badly fragmented.
>
> My point here is just no need to align any limit.
>
> Smash a good enough value here is enough, or we need to dig way deeper to 
> see if the MAX_SECTORS based one is really correct or not.

So my plan here was to also enforce the limit for buffered I/O and
provide a mempool for the maximum allocation size instead of just
failing on memory presure right now.  But there is another series
or two I need to finish first to have the buffered I/O code in the
shape where this can be easily added.