Re: [PATCH v2] mm/readahead: Fix large folio support in async readahead

[Matthew Wilcox <willy@infradead.org>]

On Tue, Nov 12, 2024 at 04:19:07PM +0100, David Hildenbrand wrote:
> Someone configured: "Don't readahead more than 128KiB"

Did they, though?  I have nothing but contempt for the thousands of
parameters that we expect sysadmins to configure.  It's ridiculous and
it needs to stop.  So, we listen to the program that has told us "We
want 2MB pages" and not to the sysadmin who hasn't changed the value of
readahead from one that was originally intended for floppy discs.

> "mm/filemap: Support VM_HUGEPAGE for file mappings" talks about "even if we
> have no history of readahead being successful".
> 
> So not about exceeding the configured limit, but exceeding the "readahead
> history".
> 
> So I consider VM_HUGEPAGE the sign here to "ignore readahead history" and
> not to "violate the config".
> 
> But that's just my opinion.

We're using the readahead code to accomplish what filemap wants.
That's an implementation detail and we shouldn't be constrained by the
limits which are in effect for normal readahead.

Normal readahead will never create a folio larger than the readahead
window.  It'll get to 256kB (eventually) and then it'll stop.  Indeed,
that was the problem this patch is addressing -- we started at 2MB then
readahead turned it down to 256kB.  Normal readahead will start at 16kB
sized folios.  This patch won't affect normal readahead at all.