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 58EB3C11D30 for ; Mon, 24 Feb 2020 16:38:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1EE5820880 for ; Mon, 24 Feb 2020 16:38:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="cj0x+qTl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1EE5820880 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 B24236B0005; Mon, 24 Feb 2020 11:38:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AADC86B0006; Mon, 24 Feb 2020 11:38:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94D1C6B0007; Mon, 24 Feb 2020 11:38:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 79E236B0005 for ; Mon, 24 Feb 2020 11:38:48 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 53E332C68 for ; Mon, 24 Feb 2020 16:38:48 +0000 (UTC) X-FDA: 76525579536.28.knot09_2fb5c68acc24f X-HE-Tag: knot09_2fb5c68acc24f X-Filterd-Recvd-Size: 5624 Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Feb 2020 16:38:47 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id i6so9252857otr.7 for ; Mon, 24 Feb 2020 08:38:47 -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=5gO1Y0WzjkHxYIBlGhH4yAQ+tmF9LMDtnMgPaRxoyaM=; b=cj0x+qTlOH8bogprsI1KxF0PwXK+DJOMYjbq8x5Xr0Peoeo3LPolVoXCH2d+1bFHyn cJGd+9woHFNvbMXIOehX7Uzt631Xj8BTQdWcqeMXoFhgFbKjRr7mJfKxZJ9B9dypEoi+ 0a/c7ukYfIWAmmQ2dGInzkXyM3vzdfJmtfUzx21/4NbAICg5fQ5csiFBDWljYeEiu/Kc ks5XUrla6niH4fjrg/j57lJHfVnvBdGq1Hccd9QyueUwpBWZdCtJgXSm2A8RnugrhcWq A//qAoh7mL2CDYzh7DZXY86nzBSrghF1gLfSmibRpfRYSp4ADTbJUFptp8GZpd6JsWt5 clyA== 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=5gO1Y0WzjkHxYIBlGhH4yAQ+tmF9LMDtnMgPaRxoyaM=; b=qPs0LNjupwBcb/uK6yLxtRHR8D0xVtN8LSddarukwm12EiORg+gwnEh4bzoNaze6g6 ttd0ye5TQFmEf9l8SjvwuDAYRMc/xE2N5PVgz4qhkIsAvRV8BPPpMr0nPGYXfp6XZO4g jRagBUKynH+QQP04on8jdAyVxVmIRwMEo50UPOea1pvJqVNf3RSpAK8TApe1bUmMi6i4 G+jtj8Hx2uKDk8j+OO8z2Owf0+/n/AXEW43atg7dCFb6XxzeiHe7aMrYzugXTOIcS5SS PAuzlWdIF4irIPY2TMf4UnavjmB7Sh0gbZEYQHMe0vzZqUu3ib1zdXGduTUUQU6djlig Y9Pw== X-Gm-Message-State: APjAAAUkAcGLjSbDgAe2g58O73NYwg1AFEAN72fClMbw19Pw9podYNm5 6yr1MOwACV7boDFJ4ZgTOwK5HywABNrpSg//smU3xw== X-Google-Smtp-Source: APXvYqysPXjk8gDJk/QITNaTz1FQWVQyPK2BoG7VAZDGX1W2Z7UD9Rk4eTaTNlVvaHwLmq2ty0hZHD6Yw2YU55V5t+0= X-Received: by 2002:a9d:6ac2:: with SMTP id m2mr41277314otq.191.1582562326606; Mon, 24 Feb 2020 08:38:46 -0800 (PST) MIME-Version: 1.0 References: <20200222010456.40635-1-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Mon, 24 Feb 2020 08:38:35 -0800 Message-ID: Subject: Re: [PATCH] net: memcg: late association of sock to memcg To: Eric Dumazet 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 Sun, Feb 23, 2020 at 11:29 PM Eric Dumazet wrote: > > 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. Thanks a lot. I will add that with a comment. BTW for my knowledge which field represents the transmit queue size? > > To test this patch, make sure to add a delay before accept(), so that > 2MB worth of data can be queued before accept() happens. Yes, I will test this with a delay. thanks, Shakeel