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

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 7 Nov 2024 11:39:36 +0800 Yafang Shao <laoar.shao@gmail.com> wrote:

> On Thu, Nov 7, 2024 at 5:03 AM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Wed,  6 Nov 2024 17:21:14 +0800 Yafang Shao <laoar.shao@gmail.com> wrote:
> >
> > > When large folio support is enabled and read_ahead_kb is set to a smaller
> > > value, ra->size (4MB) may exceed the maximum allowed size (e.g., 128KB). To
> > > address this, we need to add a conditional check for such cases. However,
> > > this alone is insufficient, as users might set read_ahead_kb to a larger,
> > > non-hugepage-aligned value (e.g., 4MB + 128KB). In these instances, it is
> > > essential to explicitly align ra->size with the hugepage size.
> >
> > How much performance improvement is this likely to offer our users?
> 
> The performance boost comes from enabling the use of hugepages
> directly. Previously, users were unable to leverage large folios as
> expected. With this change, however, large folios are now usable as
> intended.

Thanks, but I was hoping for something quantitative.  Some nice before-
and-after testing?  How important/useful/impactful is this change?

> This improvement addresses a critical need in services like AI
> inference, which benefit substantially from hugetlbfs. However, using
> hugetlbfs effectively within containerized environments can be
> challenging. To overcome this limitation, we explored large folios as
> a more flexible and production-friendly alternative.
> 
> > IOW, should we consider backporting it?
> 
> We should consider backporting this change. We've already backported
> it to our local 6.1.y kernel, where it's performing well.
> The Fixes tag should ensure it will be included in the stable kernel, right?

For most subsystems, yes.  In MM an explicit cc:stable is needed. 
Along with a changelog which permits readers to understand why a
backport is proposed.