Re: [RFC PATCH 0/4] mm, bpf: BPF based THP adjustment

[Yafang Shao <laoar.shao@gmail.com>]

On Wed, Apr 30, 2025 at 10:40 PM Liam R. Howlett
<Liam.Howlett@oracle.com> wrote:
>
> * Yafang Shao <laoar.shao@gmail.com> [250429 22:34]:
> > On Tue, Apr 29, 2025 at 11:09 PM Zi Yan <ziy@nvidia.com> wrote:
> > >
> > > Hi Yafang,
> > >
> > > We recently added a new THP entry in MAINTAINERS file[1], do you mind ccing
> > > people there in your next version? (I added them here)
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/tree/MAINTAINERS?h=mm-everything#n15589
> >
> > Thanks for your reminder.
> > I will add the maintainers and reviewers in the next version.
> >
> > >
> > > On Mon Apr 28, 2025 at 10:41 PM EDT, Yafang Shao wrote:
> > > > In our container environment, we aim to enable THP selectively—allowing
> > > > specific services to use it while restricting others. This approach is
> > > > driven by the following considerations:
> > > >
> > > > 1. Memory Fragmentation
> > > >    THP can lead to increased memory fragmentation, so we want to limit its
> > > >    use across services.
> > > > 2. Performance Impact
> > > >    Some services see no benefit from THP, making its usage unnecessary.
> > > > 3. Performance Gains
> > > >    Certain workloads, such as machine learning services, experience
> > > >    significant performance improvements with THP, so we enable it for them
> > > >    specifically.
> > > >
> > > > Since multiple services run on a single host in a containerized environment,
> > > > enabling THP globally is not ideal. Previously, we set THP to madvise,
> > > > allowing selected services to opt in via MADV_HUGEPAGE. However, this
> > > > approach had limitation:
> > > >
> > > > - Some services inadvertently used madvise(MADV_HUGEPAGE) through
> > > >   third-party libraries, bypassing our restrictions.
> > >
> > > Basically, you want more precise control of THP enablement and the
> > > ability of overriding madvise() from userspace.
> > >
> > > In terms of overriding madvise(), do you have any concrete example of
> > > these third-party libraries? madvise() users are supposed to know what
> > > they are doing, so I wonder why they are causing trouble in your
> > > environment.
> >
> > To my knowledge, jemalloc [0] supports THP.
> > Applications using jemalloc typically rely on its default
> > configurations rather than explicitly enabling or disabling THP. If
> > the system is configured with THP=madvise, these applications may
> > automatically leverage THP where appropriate
>
> Isn't jemalloc THP aware and can be configured to always, never, or
> "default to the system setting" use THP for both metadata and
> allocations? It seems like this is an example of a thrid party library
> that knows what it is doing in regards to THP. [1]

Thanks for your explanation.

>
> If jemalloc is not following its own settings then it is an issue in
> jemalloc and not a reason for a kernel change.

We don’t change the kernel to accommodate specific userspace
settings—we change it only when it benefits users more broadly.

By the way, this patchset isn’t intended to address that issue. If
it’s causing confusion about the problem this patchset is trying to
solve, I’ll remove that part from the commit log in the next version.

>
> If you are relying on the default configuration of jemalloc and it
> doesn't work as you expect, then maybe try the thp settings?
>
> >
> > [0]. https://github.com/jemalloc/jemalloc
>
> ...
>
> Thanks,
> Liam
>
> [1]. https://jemalloc.net/jemalloc.3.html



-- 
Regards
Yafang