Re: [LSF/MM/BPF TOPIC] Using BPF in MM

[Vernon Yang <vernon2gm@gmail.com>]

On Tue, Apr 28, 2026 at 10:12:16AM +0200, David Hildenbrand (Arm) wrote:
> On 4/28/26 01:57, Roman Gushchin wrote:
> > [LSF/MM/BPF TOPIC] Using BPF in MM
> > ----------------------------------
> >
> > Over the last decade, BPF successfully penetrated into multiple kernel
> > subsystems: started as a feature to filter (out) networking packets,
> > it captured its place in networking, tracing, security, HID drivers,
> > and scheduling. Memory management is a logical next step, and recently
> > we saw a growing number of proposals in this area.
> >
> > In (approximately) historical order:
> >   - BPF OOM
> >   - BPF-based memcg stats access (landed)
> >   - BPF-based NUMA balancing
> >   - eBPF-mm
> >   - cache_ext (BPF Page Cache)
> >   - memcg_ext
>
> There was also the BPF THP control.

Hi David, Roman,

I submit a new series "mm: introduce mthp_ext via cgroup-bpf to make
mTHP more transparent"[1] to implement BPF-THP, which has excellent
performance data through stress testing. For details, please refer to
the patchset cover letter.

Although I did not attend the conference in person, I have been online
throughout. Please feel free to discuss any latest progress with me
online. Thank you!

[1] https://lore.kernel.org/linux-mm/20260503165024.1526680-1-vernon2gm@gmail.com/

--
Cheers,
Vernon

> >
> > There are some obvious target which haven't been covered yet:
> >   - BPF-driven readahead control
> >   - BPF-driven KSM
> >   - BPF-driven guest memory control
> >
> > Despite a large number of suggestions only a relatively small feature
> > (query memcg statistics from BPF) made it to upstream.
> >
> > It looks like using BPF in the MM subsystem comes with a set of somewhat
> > unique challenges and questions to be answered.
>
> [...]
>
> I think you are missing one of the most important points: Unclear ABI stability
> guarantees.
>
> One the one hand, we are told that there are no ABI stability guarantees, and
> that we can change hooks (add/remove/modify) any time we want.
>
> On the other hand, as soon as there is some ebpf program out there that we
> break, you can rest assured that there will be trouble.
>
> In the area of THP, where we don't even know which hooks we will need long term
> and how they would look like, that was one of the reasons why the BPF THP
> control was rejected.
>
> --
> Cheers,
>
> David
>