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.
