Message-ID: <CALOAHbBcU1m=2siwZn10MWYyNt15Y=3HwSGi7+t-YPWf0n=VRg@mail.gmail.com>
Date: Wed, 8 Oct 2025 11:50:22 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, David Hildenbrand <david@...hat.com>, ziy@...dia.com, 
	baolin.wang@...ux.alibaba.com, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	Liam Howlett <Liam.Howlett@...cle.com>, npache@...hat.com, ryan.roberts@....com, 
	dev.jain@....com, Johannes Weiner <hannes@...xchg.org>, usamaarif642@...il.com, 
	gutierrez.asier@...wei-partners.com, Matthew Wilcox <willy@...radead.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Amery Hung <ameryhung@...il.com>, 
	David Rientjes <rientjes@...gle.com>, Jonathan Corbet <corbet@....net>, 21cnbao@...il.com, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Tejun Heo <tj@...nel.org>, lance.yang@...ux.dev, 
	Randy Dunlap <rdunlap@...radead.org>, bpf <bpf@...r.kernel.org>, 
	linux-mm <linux-mm@...ck.org>, "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 mm-new 03/11] mm: thp: add support for BPF based THP
 order selection

On Wed, Oct 8, 2025 at 11:25 AM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Tue, Oct 7, 2025 at 1:47 AM Yafang Shao <laoar.shao@...il.com> wrote:
> > has shown that multiple attachments often introduce conflicts. This is
> > precisely why system administrators prefer to manage BPF programs with
> > a single manager—to avoid undefined behaviors from competing programs.
>
> I don't believe this a single bit.

You should spend some time seeing how users are actually applying BPF
in practice. Some information for you :

https://github.com/bpfman/bpfman
https://github.com/DataDog/ebpf-manager
https://github.com/ccfos/huatuo

> bpf-thp didn't have any
> production exposure.
>  Everything that you said above is wishful thinking.

The statement above applies to other multi-attachable programs, not to bpf-thp.

> In actual production every programmable component needs to be
> scoped in some way. One can argue that scheduling is a global
> property too, yet sched-ext only works on a specific scheduling class.

I can also argue that bpf-thp only works on a specific thp mode
(madvise and always) ;-)

> All bpf program types are scoped except tracing, since kprobe/fentry
> are global by definition, and even than multiple tracing programs
> can be attached to the same kprobe.
>
> > execution. In other words, it is functionally a variant of fmod_ret.
>
> hid-bpf initially went with fmod_ret approach, deleted the whole thing
> and redesigned it with _scoped_ struct-ops.

I see little value in embedding a bpf_thp_struct_ops into the
task_struct. The benefits don't appear to justify the added
complexity.

>
> > If we allow multiple attachments and they return different values, how
> > do we resolve the conflict?
> >
> > If one program returns order-9 and another returns order-1, which
> > value should be chosen? Neither 1, 9, nor a combination (1 & 9) is
> > appropriate.
>
> No. If you cannot figure out how to stack multiple programs
> it means that the api you picked is broken.
>
> > A single global program is a natural and logical extension of the
> > existing global /sys/kernel/mm/transparent_hugepage/ interface. It is
> > a good fit for BPF-THP and avoids unnecessary complexity.
>
> The Nack to single global prog is not negotiable.

We still lack a compelling technical reason for embedding
bpf_thp_struct_ops into task_struct. Can you clearly articulate the
problem that this specific design is solving?

-- 
Regards
Yafang

Powered by blists - more mailing lists