linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	 Josh Poimboeuf <jpoimboe@kernel.org>,
	Jeff Layton <jlayton@kernel.org>,
	 Chuck Lever <chuck.lever@oracle.com>,
	Kees Cook <kees@kernel.org>,  Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	 David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 Roman Gushchin <roman.gushchin@linux.dev>,
	 Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	 Michal Hocko <mhocko@kernel.org>,
	Shakeel Butt <shakeelb@google.com>,
	 Muchun Song <muchun.song@linux.dev>,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	 Vlastimil Babka <vbabka@suse.cz>
Subject: [PATCH RFC 0/4] memcg_kmem hooks refactoring and kmem_cache_charge()
Date: Fri, 01 Mar 2024 18:07:07 +0100	[thread overview]
Message-ID: <20240301-slab-memcg-v1-0-359328a46596@suse.cz> (raw)

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>



             reply	other threads:[~2024-03-01 17:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 17:07 Vlastimil Babka [this message]
2024-03-01 17:07 ` [PATCH RFC 1/4] mm, slab: move memcg charging to post-alloc hook Vlastimil Babka
2024-03-12 18:52   ` Roman Gushchin
2024-03-12 18:59     ` Matthew Wilcox
2024-03-12 20:35       ` Roman Gushchin
2024-03-13 10:55     ` Vlastimil Babka
2024-03-13 17:34       ` Roman Gushchin
2024-03-15  3:23   ` Chengming Zhou
2024-03-01 17:07 ` [PATCH RFC 2/4] mm, slab: move slab_memcg hooks to mm/memcontrol.c Vlastimil Babka
2024-03-12 18:56   ` Roman Gushchin
2024-03-12 19:32     ` Matthew Wilcox
2024-03-12 20:36       ` Roman Gushchin
2024-03-01 17:07 ` [PATCH RFC 3/4] mm, slab: introduce kmem_cache_charge() Vlastimil Babka
2024-03-01 17:07 ` [PATCH RFC 4/4] UNFINISHED mm, fs: use kmem_cache_charge() in path_openat() Vlastimil Babka
2024-03-01 17:51   ` Linus Torvalds
2024-03-01 18:53     ` Roman Gushchin
2024-03-12  9:22       ` Vlastimil Babka
2024-03-12 19:05         ` Roman Gushchin
2024-03-04 12:47     ` Christian Brauner
2024-03-24  2:27     ` Al Viro
2024-03-24 17:44       ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240301-slab-memcg-v1-0-359328a46596@suse.cz \
    --to=vbabka@suse.cz \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=cl@linux.com \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox