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

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

On Fri, Nov 28, 2025 at 3:57 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> TL;DR - NAK this series as-is.
>
> On Fri, Nov 28, 2025 at 10:53:53AM +0800, Yafang Shao wrote:
> > Thank you for sharing this.
> > However, BPF-THP is already deployed across our server fleet and both
> > our users and my boss are satisfied with it. As such, we are not
> > considering a switch. The current solution also offers us a valuable
> > opportunity to experiment with additional policies in production.
>
> Sorry Yafang, this isn't how upstream works.
>
> I've not been paying attention to this series as I have been waiting for
> you and Alexei to reach some kind of resolution before diving back in.
>
> But your response here is _very_ concerning to me.
>
> Of course you're welcome to deploy unmerged arbitrary patches to your
> kernel (as long as you abide by the GPL naturally).
>
> But we've made it _very_ clear that this is an - experimental - feature,
> that might go away at any time, while we iterate and determine how useful
> it might be to users in general.
>
> Now it seems that exactly the thing I feared has already happened - people
> ignoring the fact we are hiding this behind an, in effect,
> CONFIG_EXPERIMENTAL_PLEASE_DO_NOT_RELY_ON_THIS flag.

Thank you for your concern. We have a dedicated kernel team that
maintains our runtime. Our standard practice for new kernel features
is to first validate them in our production environment. This ensures
that any feature we propose to upstream has been proven in a
real-world, large-scale use case.

>
> This means that I am no longer confident this approach is going to work,
> which inclines me to reject this proposal outright.
>
> The bar is now a lot higher in my view, and now we're going to need
> extensive and overwhelming evidence that whatever BPF hook we provide is
> both future proof as to how we intend THP to develop and of use to more
> than one user.
>
> Again as David mentioned, you seem to be able to achieve what you want to
> achieve via the extensions we added to PR_SET_THP_DISABLE.

We see no compelling reason to switch to PR_SET_THP_DISABLE. BPF-THP
has proven to be perfectly stable across our production fleet, and we
have the full capability to maintain it.

>
> That then reduces the number of users of this feature to 0 and again
> inclines me to reject this approach entirely.

I understand your concern. Our intention is simply to contribute a
feature that we have found valuable in production, in the hope that it
may benefit others as well. We of course respect the upstream process
and are fully prepared for the possibility that it may not be
accepted.

>
> So for now it's a NAK.
>
> >
> > In summary, I am fine with either the per-MM or per-MEMCG method.
> > Furthermore, I don't believe this is an either-or decision; both can
> > be implemented to work together.
>
> No, it is - the global approach is broken and we won't be having that.

Let me rephrase for clarity: I see the per-MM and per-MEMCG approaches
as compatible. They can be implemented together, potentially as a
hybrid approach.

-- 
Regards
Yafang