linux-kernel - [PATCH RFC 0/4] memcg_kmem hooks refactoring and kmem_cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Fri, 01 Mar 2024 18:07:07 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Linus Torvalds <torvalds@...ux-foundation.org>, 
 Josh Poimboeuf <jpoimboe@...nel.org>, Jeff Layton <jlayton@...nel.org>, 
 Chuck Lever <chuck.lever@...cle.com>, Kees Cook <kees@...nel.org>, 
 Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, 
 David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, 
 Andrew Morton <akpm@...ux-foundation.org>, 
 Roman Gushchin <roman.gushchin@...ux.dev>, 
 Hyeonggon Yoo <42.hyeyoo@...il.com>, Johannes Weiner <hannes@...xchg.org>, 
 Michal Hocko <mhocko@...nel.org>, Shakeel Butt <shakeelb@...gle.com>, 
 Muchun Song <muchun.song@...ux.dev>, 
 Alexander Viro <viro@...iv.linux.org.uk>, 
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
 cgroups@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
 Vlastimil Babka <vbabka@...e.cz>
Subject: [PATCH RFC 0/4] memcg_kmem hooks refactoring and
 kmem_cache_charge()

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@...e.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@...e.cz>