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=ham 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 E73DCC35670 for ; Sat, 22 Feb 2020 01:54:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA62C207FD for ; Sat, 22 Feb 2020 01:54:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="RHl51ojs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA62C207FD 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 452F66B0006; Fri, 21 Feb 2020 20:54:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 428216B0007; Fri, 21 Feb 2020 20:54:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 365A16B0008; Fri, 21 Feb 2020 20:54:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id 1F1CB6B0006 for ; Fri, 21 Feb 2020 20:54:56 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C6377181AEF1D for ; Sat, 22 Feb 2020 01:54:55 +0000 (UTC) X-FDA: 76516094550.02.hair72_48152143b972e X-HE-Tag: hair72_48152143b972e X-Filterd-Recvd-Size: 5241 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Sat, 22 Feb 2020 01:54:55 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id j20so3847615otq.3 for ; Fri, 21 Feb 2020 17:54:55 -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=sw7GUZ8pSeTtd2D2gBjMqfVeJ6NiOruxqtzQHUcbXAE=; b=RHl51ojseo7iryCem5GSsxvnC3ShVs3uMsdYTB/dvjcL2ajlQMa+5vHX1oFp//4BRD Ox4SCW1s6tUDg0ECSWE5b0dWoY1XLsw0p8h1op0TLp55JMD2lXWxT8s5730OatksAgcy kGuyRceUWy+zrrBkZFmTnQU9VsI2cBUGSo491ie/es5JJ9C+RhHbnj0brJJZtSxjmWH9 ZxPPrwBlCDDgvYW3KdYjZc94tAWvw2JNynNaMJkAaUnvOGCl/gaO6jBJb1xyDogSQ/Uv PUGCmp/AFfqBM5w52zSxo3gpfAtTDMeu8P/Hj63dqUcORBbMWXcd2yvixbNsHPh91+lh Gt2A== 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=sw7GUZ8pSeTtd2D2gBjMqfVeJ6NiOruxqtzQHUcbXAE=; b=TzUZ9/BVWVQ6rXnsoIkNfCzjiFuqjgdp9nysMNCH/aGffValsME5zjHN71Sxv26QRS KrngEag9hCZ4OCgWyHX4yQHoC4afnavUuVTUkU9dfGRFrLWHHJE3tsNAqY0MPUGfxXr3 /ixsOTACe+lJ720lcUq1r/5cSOXSlq9fX+Pz9BVc8UmQDPFot0bmAEpGpG/fjb7k495a TzbJUIV63AHxwIHbKUorKlmDnECzQQIn5iI/B2Dazr8cKV/1JS/zNzqsIiuAWZLivS+I BH2IKjPnOQUW0SKDKu7iItOdMLgSiAsC58huwrjvo64nVlcYVY83GoQ8xSN2m3JRx5Zw FRfg== X-Gm-Message-State: APjAAAV4aVOqMEBZO3quMGTVoCXWic165gx49zZyba8WMGi+ppdys6nn s3a5+qiCQP+iJ5w8ctHQu0qVGoIwxI5j/V9IeyiVCw== X-Google-Smtp-Source: APXvYqwA2FLdzOYAZnzv8L6gxTKWf/O7OoyWGLV81E0wtW5gnT6B29/EwVNKaP1myT00aDYqCcKhzWES2cnjryeszMw= X-Received: by 2002:a05:6830:1e2b:: with SMTP id t11mr31146916otr.81.1582336494304; Fri, 21 Feb 2020 17:54:54 -0800 (PST) MIME-Version: 1.0 References: <20200222010456.40635-1-shakeelb@google.com> <20200222014850.GC459391@carbon.DHCP.thefacebook.com> In-Reply-To: <20200222014850.GC459391@carbon.DHCP.thefacebook.com> From: Shakeel Butt Date: Fri, 21 Feb 2020 17:54:43 -0800 Message-ID: Subject: Re: [PATCH] net: memcg: late association of sock to memcg To: Roman Gushchin Cc: Eric Dumazet , Johannes Weiner , Michal Hocko , Andrew Morton , "David S . Miller" , Alexey Kuznetsov , netdev@vger.kernel.org, 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:49 PM Roman Gushchin wrote: > > On Fri, Feb 21, 2020 at 05:04:56PM -0800, 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 > > Hello, Shakeel! > > > --- > > 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)); > > + } > > Looks good for me from the memcg side. Let's see what networking people will say... > > Btw, do you plan to make a separate patch for associating the socket with the default > cgroup on the unified hierarchy? I mean cgroup_sk_alloc(). > Yes. I tried to do that here but was not able to do without adding the (newsk->sk_cgrp_data.val) check which I can not do in this file as sk_cgrp_data might not be compiled. I will send a separate patch. Shakeel