Re: [RFC PATCH 0/4] mm, bpf: BPF based THP adjustment

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

On Thu, May 1, 2025 at 2:00 AM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Wed, Apr 30, 2025 at 10:38:10PM +0800, Yafang Shao wrote:
> > On Wed, Apr 30, 2025 at 9:19 PM Zi Yan <ziy@nvidia.com> wrote:
> > > For task-level control, why not using prctl(PR_SET_THP_DISABLE)?
> >
> > You’ll need to modify the user-space code—and again, this likely
> > wouldn’t be a concern if you were managing a large fleet of servers.
>
> These flags are propagated along the process tree, so you only need to
> tweak the management software that launches the container
> workload. Which is presumably the same entity that would tweak cgroup
> settings.

Right, we can modify the parent process code. In a containerized
environment, that would mean modifying the containerd source code.
However, deploying such changes is far from simple:

1. We'd need to deploy the modified containerd to our production servers.
2. All running services would need to be restarted.
3. We'd have to coordinate with teams whose services don’t benefit
from THP to ensure their cooperation.
4. Only then could we set “thp=always” across our production servers.
5. Next, we’d annotate the services that do benefit from THP, restart
them, and monitor behavior.
6. If anything goes wrong, we may have to repeat the process.
7. For systemd-managed services, we might need to implement a separate solution.

This is a painful and disruptive process. In contrast, with the
BPF-based solution, we simply introduce a plugin. Only the services
that want to use THP need to restart, and they’re generally willing to
do so since they benefit from it.

As you mentioned in another email, this entire process is
experimental, so it’s very likely that we’ll encounter unexpected
issues. That’s why flexibility and ease of adjustment are critical.

By the way, I have another draft that hooks into the fork() procedure
using BPF to adjust per-process attributes of services, aiming to
simplify deployment—but that’s a separate topic.

>
> > > For service-level control, there was a proposal of adding cgroup based
> > > THP control[1]. You might need a strong use case to convince people.
> > >
> > > [1] https://lore.kernel.org/linux-mm/20241030083311.965933-1-gutierrez.asier@huawei-partners.com/
> >
> > Thanks for the reference. I've reviewed the related discussion, and if
> > I understand correctly, the proposal was rejected by the maintainers.
>
> Cgroups are for nested trees dividing up resources. They're not a good
> fit for arbitrary, non-hierarchical policy settings.

Thanks for the explanation.

-- 
Regards
Yafang