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

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 11/28/25 03:53, Yafang Shao wrote:
> On Thu, Nov 27, 2025 at 7:48 PM David Hildenbrand (Red Hat)
> <david@kernel.org> wrote:

Lorenzo commented on the upstream topic, let me mostly comment on the 
other parts:
>>> Attaching st_ops to task_struct or to mm_struct is a can of worms.
>>> With cgroup-bpf we went through painful bugs with lifetime
>>> of cgroup vs bpf, dying cgroups, wq deadlock, etc. All these
>>> problems are behind us. With st_ops in mm_struct it will be more
>>> painful. I'd rather not go that route.
>>
>> That's valuable information, thanks. I would have hoped that per-MM
>> policies would be easier.
> 
> The per-MM approach has a performance advantage over per-MEMCG
> policies. This is because it accesses the policy hook directly via
> 
>    vma->vm_mm->bpf_mm->policy_hook()
> 
> whereas the per-MEMCG method requires a more expensive lookup:
> 
>    memcg = get_mem_cgroup_from_mm(vma->vm_mm);
>    memcg->bpf_memcg->policy_hook();
> > This lookup could be a concern in a critical path. However, this
> performance issue in the per-MEMCG mode can be mitigated. For
> instance, when a task is added to a new memcg, we can cache the hook
> pointer:
> 
>    task->mm->bpf_mm->policy_hook = memcg->bpf_memcg->policy_hook
> 
> Ultimately, we might still introduce a mm_struct:bpf_mm field to
> provide an efficient interface.

Right, caching is what I would have proposed. I would expect some 
headakes with lifetime, but probably nothing unsolvable.


>> Sounds like cgroup-bpf has sorted
>> out most of the mess.
> 
> No, the attach-based cgroup-bpf has proven to be ... a "can of worms"
> in practice ...
>   (I welcome corrections from the BPF maintainers if my assessment is
> inaccurate.)

I don't know what's right or wrong here, as Alexei said the "mm_struct" 
based one would be a can of worms and that the the cgroup-based one 
apparently solved these issues ("All these problems are behind us."), 
that's why I asked for some clarifications. :)

[...]

>>
>> Some of what Yafang might want to achieve could maybe at this point be
>> maybe achieved through the prctl(PR_SET_THP_DISABLE) support, including
>> extensions we recently added [1].
>>
>> Systemd support still seems to be in the works [2] for some of that.
>>
>>
>> [1] https://lwn.net/Articles/1032014/
>> [2] https://github.com/systemd/systemd/pull/39085
> 
> 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.

Just to emphasize: we usually don't add two mechanisms to achieve the 
very same end goal. There really must be something delivering more value 
for us to accept something more complex. Focusing on solving a solved 
problem is not good.

If some company went with a downstream-only approach they might be stuck 
having to maintain that forever.

That's why other companies prefer upstream-first :)


Having that said, the original reason why I agreed that having bpf for 
THP can be valuable is that I see a lot more value for rapid prototyping 
and policies once you can actually control on a per-VMA basis (using vma 
size, flags, anon-vma names etc) where specific folio orders could be 
valuable, and where not. But also, possibly where we would want to waste 
memory and where not.

As we are speaking I have a customer running into issues [1] with 
virtio-balloon discarding pages in a VM and khugepaged undoing part of 
that work in the hypervisor. The workaround of telling khugepaged to not 
waste memory in all of the system really feels suboptimal when we know 
that it's only the VM memory of such VMs (with balloon deflation 
enabled) where we would not want to waste memory but still use THPs.

[1] https://issues.redhat.com/browse/RHEL-121177

-- 
Cheers

David