diff options
| author | Vlastimil Babka (SUSE) <vbabka@kernel.org> | 2026-07-27 14:54:07 +0200 |
|---|---|---|
| committer | Vlastimil Babka (SUSE) <vbabka@kernel.org> | 2026-08-04 12:30:45 +0200 |
| commit | a6172cca157f3f50c9744a8b9b563f8b14371ed9 (patch) | |
| tree | 21376edb17ba5b156d9792aefcee6a995ec81d02 /scripts/stackusage | |
| parent | d4404b0f5b8b0ff4656d018a0ddfafdbd78879e2 (diff) | |
| download | linux-next-a6172cca157f3f50c9744a8b9b563f8b14371ed9.tar.gz linux-next-a6172cca157f3f50c9744a8b9b563f8b14371ed9.zip | |
mm/slab, kfence, memcg: completely remove obj_ext for kfence objects
We have already disabled memory allocation profiling for objects
allocated for KFENCE to avoid complexity. KFENCE allocations are rare
and there can be only CONFIG_KFENCE_NUM_OBJECTS (default to 255)
outstanding ones at any time, so they are among noise in the profiling
stats.
For the same reasons, we can stop memcg_kmem accounting of kfence
objects as their memory usage will be negligible wrt any practical
memcg limits.
This allows us simplifying the code and getting rid of
is_kfence_address() checks in various places, including slab_obj_ext()'s
usage of obj_to_index(). Instead we rely on the fact that slab_obj_exts()
will now always return 0 for a kfence object's fake slab, which makes
those places unreachable.
All we need to do to keep this assumption valid is not to allocate
obj_exts for kfence objects, so the checks need to guard
alloc_slab_obj_exts() where necessary.
Suggested-by: Harry Yoo <harry@kernel.org>
Link: https://patch.msgid.link/20260727-b4-objext_split-v3-13-c29ef0f1f257@kernel.org
Reviewed-by: Hao Li <hao.li@linux.dev>
Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions
