From: Shakeel Butt <shakeelb@google.com> To: Eric Dumazet <edumazet@google.com>, Roman Gushchin <guro@fb.com> Cc: Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, "David S . Miller" <davem@davemloft.net>, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>, netdev@vger.kernel.org, Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Shakeel Butt <shakeelb@google.com> Subject: [PATCH] net: memcg: late association of sock to memcg Date: Fri, 21 Feb 2020 17:04:56 -0800 [thread overview] Message-ID: <20200222010456.40635-1-shakeelb@google.com> (raw) If a TCP socket is allocated in IRQ context or cloned from unassociated (i.e. not associated to a memcg) in IRQ context then it will remain unassociated for its whole life. Almost half of the TCPs created on the system are created in IRQ context, so, memory used by suck sockets will not be accounted by the memcg. This issue is more widespread in cgroup v1 where network memory accounting is opt-in but it can happen in cgroup v2 if the source socket for the cloning was created in root memcg. To fix the issue, just do the late association of the unassociated sockets at accept() time in the process context and then force charge the memory buffer already reserved by the socket. Signed-off-by: Shakeel Butt <shakeelb@google.com> --- net/ipv4/inet_connection_sock.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c index a4db79b1b643..df9c8ef024a2 100644 --- a/net/ipv4/inet_connection_sock.c +++ b/net/ipv4/inet_connection_sock.c @@ -482,6 +482,13 @@ struct sock *inet_csk_accept(struct sock *sk, int flags, int *err, bool kern) } spin_unlock_bh(&queue->fastopenq.lock); } + + if (mem_cgroup_sockets_enabled && !newsk->sk_memcg) { + mem_cgroup_sk_alloc(newsk); + if (newsk->sk_memcg) + mem_cgroup_charge_skmem(newsk->sk_memcg, + sk_mem_pages(newsk->sk_forward_alloc)); + } out: release_sock(sk); if (req) -- 2.25.0.265.gbab2e86ba0-goog
WARNING: multiple messages have this Message-ID (diff)
From: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> To: Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, "David S . Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>, Alexey Kuznetsov <kuznet-v/Mj1YrvjDBInbfyfbPRSQ@public.gmane.org>, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Hideaki YOSHIFUJI <yoshfuji-VfPWfsRibaP+Ru+s062T9g@public.gmane.org>, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Subject: [PATCH] net: memcg: late association of sock to memcg Date: Fri, 21 Feb 2020 17:04:56 -0800 [thread overview] Message-ID: <20200222010456.40635-1-shakeelb@google.com> (raw) If a TCP socket is allocated in IRQ context or cloned from unassociated (i.e. not associated to a memcg) in IRQ context then it will remain unassociated for its whole life. Almost half of the TCPs created on the system are created in IRQ context, so, memory used by suck sockets will not be accounted by the memcg. This issue is more widespread in cgroup v1 where network memory accounting is opt-in but it can happen in cgroup v2 if the source socket for the cloning was created in root memcg. To fix the issue, just do the late association of the unassociated sockets at accept() time in the process context and then force charge the memory buffer already reserved by the socket. Signed-off-by: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> --- net/ipv4/inet_connection_sock.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c index a4db79b1b643..df9c8ef024a2 100644 --- a/net/ipv4/inet_connection_sock.c +++ b/net/ipv4/inet_connection_sock.c @@ -482,6 +482,13 @@ struct sock *inet_csk_accept(struct sock *sk, int flags, int *err, bool kern) } spin_unlock_bh(&queue->fastopenq.lock); } + + if (mem_cgroup_sockets_enabled && !newsk->sk_memcg) { + mem_cgroup_sk_alloc(newsk); + if (newsk->sk_memcg) + mem_cgroup_charge_skmem(newsk->sk_memcg, + sk_mem_pages(newsk->sk_forward_alloc)); + } out: release_sock(sk); if (req) -- 2.25.0.265.gbab2e86ba0-goog
next reply other threads:[~2020-02-22 1:05 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-22 1:04 Shakeel Butt [this message] 2020-02-22 1:04 ` [PATCH] net: memcg: late association of sock to memcg Shakeel Butt 2020-02-22 1:04 ` Shakeel Butt 2020-02-22 1:48 ` Roman Gushchin 2020-02-22 1:48 ` Roman Gushchin 2020-02-22 1:54 ` Shakeel Butt 2020-02-22 1:54 ` Shakeel Butt 2020-02-24 7:29 ` Eric Dumazet 2020-02-24 7:29 ` Eric Dumazet 2020-02-24 7:29 ` Eric Dumazet 2020-02-24 16:38 ` Shakeel Butt 2020-02-24 16:38 ` Shakeel Butt
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=20200222010456.40635-1-shakeelb@google.com \ --to=shakeelb@google.com \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=davem@davemloft.net \ --cc=edumazet@google.com \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=kuznet@ms2.inr.ac.ru \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=yoshfuji@linux-ipv6.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.