[PATCH RFC 0/4] memcg_kmem hooks refactoring and kmem_cache_charge()

Vlastimil Babka
2024-03-01T17:07:12Z

Hi,

I have tried to look into Linus's suggestions to reduce slab memcg
accounting overhead [1] [2].

The reorganized hooks are in Patch 1 and it definitely seems like nice
cleanup on its own.

In Patch 2 I have tried to move them to mm/memcontrol.c to reduce calls
to memcg code. I hoped to see better performance, but probably didn't.

Patch 3 introduces the suggested kmem_cache_charge() API and Patch 4
tries to use it for the testcase in [1] but it's unfinished due to my
lack of VFS knowledge.

I haven't done much benchmarking yet, just in a guest VM on my desktop
for the test case from [1]. Applying patches 1+2 might have improved it
slightly, but could be noise. With 3+4 the memcg overhead is gone as
expected (the charging never happens) but due to the unfinished state I
don't know yet if the separation might hurt cases where the open()
actually succeeds.

Anyway thought I would share already so others can play with it and see
if it's a good direction to pursue (with patches 3+4). I think Patch 1
should be good to apply in any case (after more testing, and review),
not yet sure about Patch 2.

[1] https://lore.kernel.org/all/CAHk-=whYOOdM7jWy5jdrAm8LxcgCMFyk2bt8fYYvZzM4U-zAQA@mail.gmail.com/
[2] https://lore.kernel.org/all/CAHk-=whw936qzDLBQdUz-He5WK_0fRSWwKAjtbVsMGfX70Nf_Q@mail.gmail.com/

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
Vlastimil Babka (4):
mm, slab: move memcg charging to post-alloc hook
mm, slab: move slab_memcg hooks to mm/memcontrol.c
mm, slab: introduce kmem_cache_charge()
UNFINISHED mm, fs: use kmem_cache_charge() in path_openat()

fs/file_table.c | 9 +-
fs/internal.h | 1 +
fs/namei.c | 4 +-
include/linux/slab.h | 10 +++
mm/memcontrol.c | 90 ++++++++++++++++++++
mm/slab.h | 10 +++
mm/slub.c | 231 +++++++++++++++------------------------------------
7 files changed, 188 insertions(+), 167 deletions(-)
---
base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
change-id: 20240229-slab-memcg-ae6b3789c924

Best regards,
--
Vlastimil Babka <vbabka@suse.cz>