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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no 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 463C3C433DB for ; Wed, 13 Jan 2021 19:35:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9D94323339 for ; Wed, 13 Jan 2021 19:35:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D94323339 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 97AA98D008D; Wed, 13 Jan 2021 14:35:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 92ADE8D006A; Wed, 13 Jan 2021 14:35:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83FA38D008D; Wed, 13 Jan 2021 14:35:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id 7019C8D006A for ; Wed, 13 Jan 2021 14:35:00 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2DCB3180AD838 for ; Wed, 13 Jan 2021 19:35:00 +0000 (UTC) X-FDA: 77701754760.14.fan60_2d0feb827520 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 0FAE418229818 for ; Wed, 13 Jan 2021 19:35:00 +0000 (UTC) X-HE-Tag: fan60_2d0feb827520 X-Filterd-Recvd-Size: 5152 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 Jan 2021 19:34:59 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id 23so4464868lfg.10 for ; Wed, 13 Jan 2021 11:34:59 -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=5x9peSoztZZwP3wRwUEonf3kp2KcQ+8lUkdq4yGVsyU=; b=dKHEpR8cis9PjPy0+s2wYpOJqK1jNlMC+AYrUDzd55sLM4EjSEbWjXCDMiHPNN4zdh 2P193WmaFtrb6GOXbsiKGuG1Wloi2abeZNrFAXtpZZhUOExC5T4Y7XhFOH8g2JUDuMnr 7QJY6Z40GpV8nHxvfUpsZW3+7c7FoTJPu26hvBTPXgk9p7lrw8JYrysx/Pf29BLn4Ty0 Dpb5apB5yMbdw7ne2ezOVgWBtKfjA9ZjEpVGRlisyGCZ8Cmxlhu2O9RiI/lRFnLeCCOf lwBWTa7PnreEl+34r7HT3Tqu5FroOmAPNFcg2K+79LHu/GPJQHjGE8eCdAyPJW+rJsMh C7Ag== 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=5x9peSoztZZwP3wRwUEonf3kp2KcQ+8lUkdq4yGVsyU=; b=FqnEtZj3TyN/JsEzrLmiipJDSgMCh/LBc9dkpNpRtGUpgUSCw0JOvxFv9zxJTBstnz 59U1ZACGnG6IytXDBqYI2TKZnE71d3IHQa5EhFRCiqAegctR7NDBGs5jJH++9bOLcGVj /MkKJro/7HuANV+tVO3k2jc/NpI+Utz0IETslfW6AvtbAlLB8Ykr5m7oqLIArorQ0RTQ h1gy0/HQJD1x8AHqUCu9ZgRbo/Ku7s9IaLxu2gEVyoRR2SofAJIwPLO9oXUITVjggPkZ f/XkdjQubF9kLx0NbMny2qfhmRi9Q+JE6RvYHxjAGzWyfOPWODTk6miaJmazoYNvqnfH PKgw== X-Gm-Message-State: AOAM532VzwQhelaXoDWP2+fwV8aUxRqn3j9JRXo0J8WJoc04e6chFV3C 1IH8n/yK2OW5/Q66G2JcabQG2BRb0plq4p4bP7pDZQ== X-Google-Smtp-Source: ABdhPJzgEk/DkNFqYOJv7Wp3xvz2mFJqsh5LD2B6QlApDjIaztQLZ1/D3AGlb0+PbTDL2rcNBlcg0ARxuR8CLhhhOiY= X-Received: by 2002:a05:6512:32ad:: with SMTP id q13mr1443000lfe.83.1610566497883; Wed, 13 Jan 2021 11:34:57 -0800 (PST) MIME-Version: 1.0 References: <20210112214105.1440932-1-shakeelb@google.com> <20210112233108.GD99586@carbon.dhcp.thefacebook.com> <20210112234822.GA134064@carbon.dhcp.thefacebook.com> <20210113184753.GB355124@carbon.dhcp.thefacebook.com> In-Reply-To: <20210113184753.GB355124@carbon.dhcp.thefacebook.com> From: Shakeel Butt Date: Wed, 13 Jan 2021 11:34:46 -0800 Message-ID: Subject: Re: [PATCH] mm: net: memcg accounting for TCP rx zerocopy To: Roman Gushchin Cc: Arjun Roy , Johannes Weiner , Michal Hocko , Eric Dumazet , Andrew Morton , "David S . Miller" , Jakub Kicinski , Linux MM , Cgroups , netdev , Linux Kernel Mailing List 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 Wed, Jan 13, 2021 at 10:48 AM Roman Gushchin wrote: > [snip] > > > Does it mean that a page can be accounted twice (even temporarily)? > > > > > > > This was an actual consideration for this patchset that we went back > > and forth on a little bit. > > Short answer, for this patch in its current form: yes. We're calling > > mem_cgroup_charge_sock_pages() immediately prior to vm_insert_pages(); > > and the skb isn't cleaned up until afterwards. Thus we have a period > > of double charging. > > > > The pseudocode for the approach in this patch is: > > > > while skb = next skb in queue is not null: > > charge_skb_pages(skb.pages) // sets page.memcg for each page > > // at this point pages are double counted > > vm_insert_pages(skb.pages) > > free(skb) // unrefs the pages, no longer double counted > > > > An alternative version of this patch went the other way: have a short > > period of undercharging. > > > > while skb = next skb in queue is not null: > > for page in skb.pages set page.memcg > > vm_insert_pages(skb.pages) > > free(skb) // unrefs the pages. pages are now undercounted > > charge_skb_pages(nr_pages_mapped, FORCE_CHARGE) // count is now correct again > > ret > > I have to think more, but at the first look the second approach is better. > IMO forcing the charge is less of a problem than double accounting > (we're forcing sock memory charging anyway). I'm afraid that even if the > double counting is temporarily for each individual page, with a constant > traffic it will create a permanent difference. > The double accounting behavior is a bit different in cgroup v1 vs v2 world as skmem is accounted in memory for v2 and a separate tcp counter for v1. I am fine with either approaches mentioned by Arjun but I would prefer to not add complexity by doing one approach for v1 and the other for v2.