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