Re: [PATCH v12 mm-new 06/10] mm: bpf-thp: add support for global mode

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

On Wed, Nov 26, 2025 at 11:13 PM Rik van Riel <riel@surriel.com> wrote:
>
> On Tue, 2025-10-28 at 18:32 -0700, Alexei Starovoitov wrote:
> > On Sun, Oct 26, 2025 at 3:03 AM Yafang Shao <laoar.shao@gmail.com>
> > wrote:
> > >
> > > The per-process BPF-THP mode is unsuitable for managing shared
> > > resources
> > > such as shmem THP and file-backed THP. This aligns with known
> > > cgroup
> > > limitations for similar scenarios [0].
> > >
> > > Introduce a global BPF-THP mode to address this gap. When
> > > registered:
> > > - All existing per-process instances are disabled
> > > - New per-process registrations are blocked
> > > - Existing per-process instances remain registered (no forced
> > > unregistration)
> > >
> > > The global mode takes precedence over per-process instances.
> > > Updates are
> > > type-isolated: global instances can only be updated by new global
> > > instances, and per-process instances by new per-process instances.
> >
> > ...
> >
> > >         spin_lock(&thp_ops_lock);
> > > -       /* Each process is exclusively managed by a single BPF-THP.
> > > */
> > > -       if (rcu_access_pointer(mm->bpf_mm.bpf_thp)) {
> > > +       /* Each process is exclusively managed by a single BPF-THP.
> > > +        * Global mode disables per-process instances.
> > > +        */
> > > +       if (rcu_access_pointer(mm->bpf_mm.bpf_thp) ||
> > > rcu_access_pointer(bpf_thp_global)) {
> > >                 err = -EBUSY;
> > >                 goto out;
> > >         }
> >
> > You didn't address the issue and instead doubled down
> > on this broken global approach.
> >
> > This bait-and-switch patchset is frankly disingenuous.
> > 'lets code up some per-mm hack, since people will hate it anyway,
> > and I'm not going to use it either, and add this global mode
> > as a fake "fallback"...'
>
> Should things be the other way around, where
> per-process BPF THP policy overrides global
> policy?

Makes sense

>
> I can definitely see a use for global policy,
> but also a reason to override it for some
> programs or containers.

We have deployed BPF-THP across nearly all of our fleets for over six
months and have enabled THP for dozens of our services.

Based on our practical experience, the global mode has proven highly
useful as it establishes a default policy for all services. When a
specific THP policy is required for a particular service, we implement
it using dedicated BPF maps—such as thp-always, thp-madvise,
thp-never, or other custom policy maps.

That said, I also find value in combining a default global policy with
the ability to override it for certain processes or containers.

The global mode and the per-process/cgroup mode are not mutually
exclusive; they can coexist.

Through our use of BPF-THP, we have found that the most reliable
approach is to allocate all THP at the initial stage. If a service
dynamically allocates a large number of THP during runtime, it can
easily trigger compaction stalls—even on the latest upstream kernel.
Therefore, monitoring compaction stalls and memory pressure is
essential to determine when a service should stop allocating
additional THP.


--
Regards
Yafang