From: Yafang Shao <laoar.shao@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: willy@infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm/readahead: Fix large folio support in async readahead
Date: Thu, 7 Nov 2024 11:39:36 +0800 [thread overview]
Message-ID: <CALOAHbCTZAU2cBHQd7ThBwVS82PfN2XBaOkcEquFX3O2j=_uSw@mail.gmail.com> (raw)
In-Reply-To: <20241106130318.91f05382d2c0bbd2be3abff5@linux-foundation.org>
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.
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?
>
> (I bet anyone who comes across this will say "oh goody" and backport it
> anyway, so why not do this for them?)
>
--
Regards
Yafang
next prev parent reply other threads:[~2024-11-07 3:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 9:21 Yafang Shao
2024-11-06 21:03 ` Andrew Morton
2024-11-07 3:39 ` Yafang Shao [this message]
2024-11-07 4:06 ` Andrew Morton
2024-11-07 6:01 ` Yafang Shao
2024-11-07 4:52 ` Matthew Wilcox
2024-11-07 5:55 ` Yafang Shao
2024-11-07 15:00 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALOAHbCTZAU2cBHQd7ThBwVS82PfN2XBaOkcEquFX3O2j=_uSw@mail.gmail.com' \
--to=laoar.shao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox