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

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

 



* Yafang Shao <laoar.shao@xxxxxxxxx> [250429 22:34]:
> On Tue, Apr 29, 2025 at 11:09 PM Zi Yan <ziy@xxxxxxxxxx> 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]

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

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





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux