[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251020031100.49917-1-laoar.shao@gmail.com>
Date: Mon, 20 Oct 2025 11:10:50 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: akpm@...ux-foundation.org,
ast@...nel.org,
daniel@...earbox.net,
andrii@...nel.org,
martin.lau@...ux.dev,
eddyz87@...il.com,
song@...nel.org,
yonghong.song@...ux.dev,
john.fastabend@...il.com,
kpsingh@...nel.org,
sdf@...ichev.me,
haoluo@...gle.com,
jolsa@...nel.org,
david@...hat.com,
ziy@...dia.com,
lorenzo.stoakes@...cle.com,
Liam.Howlett@...cle.com,
npache@...hat.com,
ryan.roberts@....com,
dev.jain@....com,
hannes@...xchg.org,
usamaarif642@...il.com,
gutierrez.asier@...wei-partners.com,
willy@...radead.org,
ameryhung@...il.com,
rientjes@...gle.com,
corbet@....net,
21cnbao@...il.com,
shakeel.butt@...ux.dev,
tj@...nel.org,
lance.yang@...ux.dev,
rdunlap@...radead.org
Cc: bpf@...r.kernel.org,
linux-mm@...ck.org,
linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Yafang Shao <laoar.shao@...il.com>
Subject: [PATCH v11 mm-new 00/10] mm, bpf: BPF-MM, BPF-THP
History
=======
RFC v1: fmod_ret based BPF-THP hook
https://lore.kernel.org/linux-mm/20250429024139.34365-1-laoar.shao@gmail.com/
RFC v2: struct_ops based BPF-THP hook
https://lore.kernel.org/linux-mm/20250520060504.20251-1-laoar.shao@gmail.com/
RFC v4: Get THP order with interface get_suggested_order()
https://lore.kernel.org/linux-mm/20250729091807.84310-1-laoar.shao@gmail.com/
v4->v9: Simplify the interface to:
int thp_get_order(struct vm_area_struct *vma, enum tva_type type,
unsigned long orders);
https://lore.kernel.org/linux-mm/20250930055826.9810-1-laoar.shao@gmail.com/
v9->RFC v10: Scope BPF-THP to individual processes
RFC v10->v11: Remove the RFC tag
The Design
==========
Scoping BPF-THP to cgroup is rejected
-------------------------------------
As explained by Gutierrez:
1. It breaks the cgroup hierarchy when 2 siblings have different THP policies
2. Cgroup was designed for resource management not for grouping processes and
tune those processes
3. We set a precedent for other people adding new flags to cgroup and
potentially polluting cgroups. We may end up with cgroups having tens of
different flags, making sysadmin's job more complex
The related links are:
https://lore.kernel.org/linux-mm/1940d681-94a6-48fb-b889-cd8f0b91b330@huawei-partners.com/
https://lore.kernel.org/linux-mm/20241030150851.GB706616@cmpxchg.org/
So we has to scope it to process.
Scoping BPF-THP to process
--------------------------
To eliminate potential conflicts among competing BPF-THP instances, we
enforce that each process is exclusively managed by a single BPF-THP. This
approach has received agreement from David. For context, see:
https://lore.kernel.org/linux-mm/3577f7fd-429a-49c5-973b-38174a67be15@redhat.com/
When registering a BPF-THP, we specify the PID of a target task. The
BPF-THP is then installed in the task's `mm_struct`
struct mm_struct {
struct bpf_thp_ops __rcu *thp_thp;
};
Inheritance Behavior:
- Existing child processes are unaffected
- Newly forked children inherit the BPF-THP from their parent
- The BPF-THP persists across execve() calls
A new linked list tracks all tasks managed by each BPF-THP instance:
- Newly managed tasks are added to the list
- Exiting tasks are automatically removed from the list
- During BPF-THP unregistration (e.g., when the BPF link is removed), all
managed tasks have their bpf_thp pointer set to NULL
- BPF-THP instances can be dynamically updated, with all tracked tasks
automatically migrating to the new version.
This design simplifies BPF-THP management in production environments by
providing clear lifecycle management and preventing conflicts between
multiple BPF-THP instances.
Global Mode
-----------
The per-process BPF-THP mode is unsuitable for managing shared resources
such as shmem THP and file-backed THP. This aligns with known cgroup
limitations for similar scenarios:
https://lore.kernel.org/linux-mm/YwNold0GMOappUxc@slm.duckdns.org/
Introduce a global BPF-THP mode to address this gap. When registered:
- All existing per-process instances are disabled
- New per-process registrations are blocked
- Existing per-process instances remain registered (no forced unregistration)
The global mode takes precedence over per-process instances. Updates are
type-isolated: global instances can only be updated by new global
instances, and per-process instances by new per-process instances.
Yafang Shao (10):
mm: thp: remove vm_flags parameter from khugepaged_enter_vma()
mm: thp: remove vm_flags parameter from thp_vma_allowable_order()
mm: thp: add support for BPF based THP order selection
mm: thp: decouple THP allocation between swap and page fault paths
mm: thp: enable THP allocation exclusively through khugepaged
mm: bpf-thp: add support for global mode
Documentation: add BPF THP
selftests/bpf: add a simple BPF based THP policy
selftests/bpf: add test case to update THP policy
selftests/bpf: add test case for BPF-THP inheritance across fork
Documentation/admin-guide/mm/transhuge.rst | 113 +++++
MAINTAINERS | 3 +
fs/exec.c | 1 +
fs/proc/task_mmu.c | 3 +-
include/linux/huge_mm.h | 59 ++-
include/linux/khugepaged.h | 10 +-
include/linux/mm_types.h | 17 +
kernel/fork.c | 1 +
mm/Kconfig | 22 +
mm/Makefile | 1 +
mm/huge_memory.c | 7 +-
mm/huge_memory_bpf.c | 419 ++++++++++++++++++
mm/khugepaged.c | 35 +-
mm/madvise.c | 7 +
mm/memory.c | 22 +-
mm/mmap.c | 1 +
mm/shmem.c | 2 +-
mm/vma.c | 6 +-
tools/testing/selftests/bpf/config | 3 +
.../selftests/bpf/prog_tests/thp_adjust.c | 357 +++++++++++++++
.../selftests/bpf/progs/test_thp_adjust.c | 53 +++
21 files changed, 1092 insertions(+), 50 deletions(-)
create mode 100644 mm/huge_memory_bpf.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/thp_adjust.c
create mode 100644 tools/testing/selftests/bpf/progs/test_thp_adjust.c
--
2.47.3
Powered by blists - more mailing lists