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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 7, 2024 at 12:06 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 7 Nov 2024 11:39:36 +0800 Yafang Shao <laoar.shao@xxxxxxxxx> wrote:
>
> > On Thu, Nov 7, 2024 at 5:03 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Wed,  6 Nov 2024 17:21:14 +0800 Yafang Shao <laoar.shao@xxxxxxxxx> 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?

will improve the commit log.

>
> > 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.

will add a cc:stable in the next version.

-- 
Regards
Yafang





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux