From: Vlastimil Babka <vbabka@suse.cz>
To: Shakeel Butt <shakeel.butt@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
David Rientjes <rientjes@google.com>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Eric Dumazet <edumazet@google.com>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Meta kernel team <kernel-team@meta.com>,
cgroups@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v3] memcg: add charging of already allocated slab objects
Date: Fri, 30 Aug 2024 11:07:32 +0200 [thread overview]
Message-ID: <76079f79-2e72-4a59-9eae-3b05ae6b9a9e@suse.cz> (raw)
In-Reply-To: <20240829175339.2424521-1-shakeel.butt@linux.dev>
On 8/29/24 19:53, Shakeel Butt wrote:
> At the moment, the slab objects are charged to the memcg at the
> allocation time. However there are cases where slab objects are
> allocated at the time where the right target memcg to charge it to is
> not known. One such case is the network sockets for the incoming
> connection which are allocated in the softirq context.
>
> Couple hundred thousand connections are very normal on large loaded
> server and almost all of those sockets underlying those connections get
> allocated in the softirq context and thus not charged to any memcg.
> However later at the accept() time we know the right target memcg to
> charge. Let's add new API to charge already allocated objects, so we can
> have better accounting of the memory usage.
>
> To measure the performance impact of this change, tcp_crr is used from
> the neper [1] performance suite. Basically it is a network ping pong
> test with new connection for each ping pong.
>
> The server and the client are run inside 3 level of cgroup hierarchy
> using the following commands:
>
> Server:
> $ tcp_crr -6
>
> Client:
> $ tcp_crr -6 -c -H ${server_ip}
>
> If the client and server run on different machines with 50 GBPS NIC,
> there is no visible impact of the change.
>
> For the same machine experiment with v6.11-rc5 as base.
>
> base (throughput) with-patch
> tcp_crr 14545 (+- 80) 14463 (+- 56)
>
> It seems like the performance impact is within the noise.
>
> Link: https://github.com/google/neper [1]
> Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
Thanks, pushed to slab/for-next for test coverage, hopefully net people will
ack.
Also one thing:
We should add some kernel doc for this, no? Explaining when people are
supposed to use this, that objects from KMALLOC_NORMAL will be ignored, and
what the return value means (including where it's faked to be true).
> +bool kmem_cache_charge(void *objp, gfp_t gfpflags)
> +{
> + if (!memcg_kmem_online())
> + return true;
> +
> + return memcg_slab_post_charge(objp, gfpflags);
> +}
> +EXPORT_SYMBOL(kmem_cache_charge);
> +
> /**
> * kmem_cache_alloc_node - Allocate an object on the specified node
> * @s: The cache to allocate from.
> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index 64d07b842e73..3c13ca8c11fb 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -715,6 +715,7 @@ struct sock *inet_csk_accept(struct sock *sk, struct proto_accept_arg *arg)
> release_sock(sk);
> if (newsk && mem_cgroup_sockets_enabled) {
> int amt = 0;
> + gfp_t gfp = GFP_KERNEL | __GFP_NOFAIL;
>
> /* atomically get the memory usage, set and charge the
> * newsk->sk_memcg.
> @@ -731,8 +732,8 @@ struct sock *inet_csk_accept(struct sock *sk, struct proto_accept_arg *arg)
> }
>
> if (amt)
> - mem_cgroup_charge_skmem(newsk->sk_memcg, amt,
> - GFP_KERNEL | __GFP_NOFAIL);
> + mem_cgroup_charge_skmem(newsk->sk_memcg, amt, gfp);
> + kmem_cache_charge(newsk, gfp);
>
> release_sock(newsk);
> }
next prev parent reply other threads:[~2024-08-30 9:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-29 17:53 Shakeel Butt
2024-08-30 9:07 ` Vlastimil Babka [this message]
2024-08-30 19:44 ` Shakeel Butt
2024-09-01 19:34 ` Vlastimil Babka
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=76079f79-2e72-4a59-9eae-3b05ae6b9a9e@suse.cz \
--to=vbabka@suse.cz \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
/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