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

[Rik van Riel <riel@surriel.com>]

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?

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

-- 
All Rights Reversed.