From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20937C35679 for ; Mon, 24 Feb 2020 07:29:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D8F722080D for ; Mon, 24 Feb 2020 07:29:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="cT1aVW9a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8F722080D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6F5736B0005; Mon, 24 Feb 2020 02:29:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 67F016B0006; Mon, 24 Feb 2020 02:29:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 520D56B0007; Mon, 24 Feb 2020 02:29:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id 36E856B0005 for ; Mon, 24 Feb 2020 02:29:18 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B4224180AD806 for ; Mon, 24 Feb 2020 07:29:17 +0000 (UTC) X-FDA: 76524194754.05.test99_340157ea01053 X-HE-Tag: test99_340157ea01053 X-Filterd-Recvd-Size: 5188 Received: from mail-yw1-f66.google.com (mail-yw1-f66.google.com [209.85.161.66]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Feb 2020 07:29:17 +0000 (UTC) Received: by mail-yw1-f66.google.com with SMTP id n184so4814109ywc.3 for ; Sun, 23 Feb 2020 23:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pu7YZUk9S4E/pNGkKq9v6WlWWKovjGT+ogGtMRUpTlY=; b=cT1aVW9aEmNffyJsbSnpD1pePBSTJmnbrzeS1G1xYMa+f/EI6Ix7TCrDA2k7COPesT nCNnqeSTzMOzj9Dop4WbLhHHv4N6u/cpIlGFjewYNHHviMvEopaL5JfcJWNiNYOy828a 5q0KS5TdQWwz9hJAk7r952F3mLit5GROR1edHOg1LGu+yE8oWQ3LB3TLurElJ+N/IUhS yJOqnGyl9XxLMZrwR8wmW/j6Hkht8FySi7RJe6fJtKM5dYhMdn9bTuo8r9THb3skjq7K /3mYHGC5MFfzeDS085t/m1H8wI9bVvbmxd3lRfq7AH9PkcpWJXQWmBQKz0NmH5Zm2SVy CC+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pu7YZUk9S4E/pNGkKq9v6WlWWKovjGT+ogGtMRUpTlY=; b=iz7bkFLBOiATFOsZ9AZoArOLcxHh3krUNBWb0lAtzhexwm83ks/FLGz0eINX4pluQ6 ZGn+hFit49u2Mx8X79onFkJdyEDufvBsThQrKB2d7AlwFgUHiinzqRdd1hpJ+KXxnv2Y lSjw8+NxWfTUAxf+GwmwFlqIaTILj6p9SRdbaPCa0RQTph8VjNV9YqKP6hx9KWXAXAzk Lx5hxKJv4CSm55BLYFEpahBN52DBxxzqBq4YIAMNsBzK1xWA3dIaEomn2tFEcpblZ2UB yRziFsyGv0PZv2F20XR0f/MnFulRnF+mb1UFr0if9SyJvD2vSDE2Bg4mBFbkM/dBZzD9 McaA== X-Gm-Message-State: APjAAAVtz/mDqQl6yPSgmU+Gh/q0roWPSomPoyQBhCPS9I5idre5U7MQ JP5HxYmaycP3I7pcltVy7EMc7F8C6vpPHN59Jw3H4g== X-Google-Smtp-Source: APXvYqxZIwuqqBEDmmlfQUkUBgpzYL2C3CpS2lE4a1qMVtMJH7Paj2i9si0t8xcdBW8R0TX6IMVC8K2dWXRjAM3RHXU= X-Received: by 2002:a81:3a06:: with SMTP id h6mr39722556ywa.170.1582529356484; Sun, 23 Feb 2020 23:29:16 -0800 (PST) MIME-Version: 1.0 References: <20200222010456.40635-1-shakeelb@google.com> In-Reply-To: <20200222010456.40635-1-shakeelb@google.com> From: Eric Dumazet Date: Sun, 23 Feb 2020 23:29:04 -0800 Message-ID: Subject: Re: [PATCH] net: memcg: late association of sock to memcg To: Shakeel Butt Cc: Roman Gushchin , Johannes Weiner , Michal Hocko , Andrew Morton , "David S . Miller" , Alexey Kuznetsov , netdev , Hideaki YOSHIFUJI , linux-mm , Cgroups , LKML Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 21, 2020 at 5:05 PM Shakeel Butt wrote: > > 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 > --- > 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)); I am not sure what you are trying to do here. sk->sk_forward_alloc is not the total amount of memory used by a TCP socket. It is only some part that has been reserved, but not yet consumed. For example, every skb that has been stored in TCP receive queue or out-of-order queue might have used memory. I guess that if we assume that a not yet accepted socket can not have any outstanding data in its transmit queue, you need to use sk->sk_rmem_alloc as well. To test this patch, make sure to add a delay before accept(), so that 2MB worth of data can be queued before accept() happens. Thanks.