Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3755963pxf; Mon, 22 Mar 2021 14:21:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1Kb45dHxC1KdyJt+W3iDNLu2rOItC2ytrNmzgoOQfnfmmwNcp4ReC5gzAn7WX/FUoF+ec X-Received: by 2002:a17:906:7f84:: with SMTP id f4mr1607637ejr.525.1616448064091; Mon, 22 Mar 2021 14:21:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616448064; cv=none; d=google.com; s=arc-20160816; b=NjBUkbotLoHjEPEjfJFoswdhKGGDVkG/Hxi7phERA6uqJIdqlDIrUXWfCEsH7wOSTZ CUXZtUU0wRATo5/YweNabZJED2ul/EAVKeuEKknmR8euIZP4CKWeHz8MrtqNYtRUzBsk 9MEQdugoQtZq8hzEzyISwHSAgs5O7GscX/YGH2J9LoPTfew9jHySviR3BVjeZbOryPed vMqNnjOtUwNGO4GsvwdKk+K/b0isjdr0Cv052Ko3CjkBv1M400/ZFeM3Cehl5xoz2R0F SwQUzliS233+i7eWn9dBYCpEv08zQCDP5seQmY28L4S1u549NLLeYbzQvY+ZvGos97mo 7o5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=gyGz6jIAyesHb03GrLq2sQ8gNXK0GEF8U0hfkl4YQos=; b=BbaY+mUDdsR523siXCGvforFdKe6RhJ+dCYeOmRnEasW/PxMsNNk6BsJQPPsHKXTxm 0AAXob0nFpSwhErIXGUH/9+C4OsJTEmO1Kh50SkgYCXHhSdZTlDf1RgTOywap+hCOW2x Tap0SgCxc2K2ca1+inyBiZHmOOAA6j7QkcdGGqzrsWyrFx616CLR2Oh5o5pamJHUXqVC df1UtMjnJcD/AL0Nr34WQV1S0Lreo5HvRjiE6p5FomRj2vuEy48L3J5ZKPatM/XrFPqJ demDPHuTjLZR5WHHxcYIsyzCQZ6oB+RrlGWL9ocEpUfJ4U6Zmm6LIUUpeF/vLWh+Cjs5 LlWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WFU7Cd+K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g20si12090816ejf.364.2021.03.22.14.20.41; Mon, 22 Mar 2021 14:21:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WFU7Cd+K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230320AbhCVVTo (ORCPT + 99 others); Mon, 22 Mar 2021 17:19:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231160AbhCVVTV (ORCPT ); Mon, 22 Mar 2021 17:19:21 -0400 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D8F0C061762 for ; Mon, 22 Mar 2021 14:19:20 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id a22-20020a17090aa516b02900c1215e9b33so11230239pjq.5 for ; Mon, 22 Mar 2021 14:19:20 -0700 (PDT) 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=gyGz6jIAyesHb03GrLq2sQ8gNXK0GEF8U0hfkl4YQos=; b=WFU7Cd+KSjhmC3zYLefyH/pznYkILEn4gUYD7fgJdX15GrVZXGIjvctmLzMcUMehix DBe1X1g3cy/+Fh385KsKSImJA5ngvSqHLfHMA2T/6M2Vzm0ArF8tP3xMXk2oKzX9jfCl /eFW9cpATHI9XDuToVZyvmbnwaxiZJE2ZKS6JAw1kodd+wtBYwgc1/INQS7ISYzJ2lrA Dtyq6CFbKILtk389p0xzfizKYo9bBAoYISMoZZmM22cKcI3MpJgHYdEhXvpscEVor9kl cdao8Wx9Ba+End5w8sZotV3yefDZwsz6ZyKzGmtgPONmz3bCJRLPfX9axapxptljnzDF ogTQ== 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=gyGz6jIAyesHb03GrLq2sQ8gNXK0GEF8U0hfkl4YQos=; b=DQbowxVXS1G+ymi6dw0d0fgNrBklak9QSJ7G7N/Cc+J4FlEm1hi6ybkczg1gTAI7NC 9fvdLy1uW/bJbRFNODrC0XTx15oDytG1RltHQOFvgsoO+Lx4pHxVe8/wNKSynLWAaAsM Q+vL3jC5ye7GUw3kr1/88nEJ9zdPdNUCoUwQsLFo6tUyr0TlwuXAxO+LKUWLh+LhVmsn h34B3hPbYyahVZSEvPk8rCzR64BZ2W6C/20eT98T6JWibe69Ce0LrWkDVncbb5NU/TqM TP/rjsxaLPNdfSYTu3nd7jPQv0mTI/zVBucX+QVAMbGUOC4BChU+dbDfMxLvlk0X7LXL ACtQ== X-Gm-Message-State: AOAM531j4r13trRwkJ8R3R9WDJh5NWz21jy85L4Xu2zIgHv08SeDCxT3 hwEcerW5X/DnnqAjq3pts3zQtV00vweLnRXm34hlXZN4ZYw= X-Received: by 2002:a17:90a:9d82:: with SMTP id k2mr1017479pjp.48.1616447959140; Mon, 22 Mar 2021 14:19:19 -0700 (PDT) MIME-Version: 1.0 References: <20210316013003.25271-1-arjunroy.kdev@gmail.com> <20210317202123.7d2eaa0e54c36c20571a335c@linux-foundation.org> In-Reply-To: <20210317202123.7d2eaa0e54c36c20571a335c@linux-foundation.org> From: Arjun Roy Date: Mon, 22 Mar 2021 14:19:08 -0700 Message-ID: Subject: Re: [mm, net-next v2] mm: net: memcg accounting for TCP rx zerocopy To: Andrew Morton Cc: Arjun Roy , David Miller , netdev , Linux Kernel Mailing List , Cgroups , Linux MM , Shakeel Butt , Eric Dumazet , Soheil Hassas Yeganeh , Jakub Kicinski , Michal Hocko , Johannes Weiner , Yang Shi , Roman Gushchin Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 17, 2021 at 8:21 PM Andrew Morton wrote: > > On Mon, 15 Mar 2021 18:30:03 -0700 Arjun Roy wrote: > > > From: Arjun Roy > > > > TCP zerocopy receive is used by high performance network applications > > to further scale. For RX zerocopy, the memory containing the network > > data filled by the network driver is directly mapped into the address > > space of high performance applications. To keep the TLB cost low, > > these applications unmap the network memory in big batches. So, this > > memory can remain mapped for long time. This can cause a memory > > isolation issue as this memory becomes unaccounted after getting > > mapped into the application address space. This patch adds the memcg > > accounting for such memory. > > > > Accounting the network memory comes with its own unique challenges. > > The high performance NIC drivers use page pooling to reuse the pages > > to eliminate/reduce expensive setup steps like IOMMU. These drivers > > keep an extra reference on the pages and thus we can not depend on the > > page reference for the uncharging. The page in the pool may keep a > > memcg pinned for arbitrary long time or may get used by other memcg. > > > > This patch decouples the uncharging of the page from the refcnt and > > associates it with the map count i.e. the page gets uncharged when the > > last address space unmaps it. Now the question is, what if the driver > > drops its reference while the page is still mapped? That is fine as > > the address space also holds a reference to the page i.e. the > > reference count can not drop to zero before the map count. > > What tree were you hoping to get this merged through? I'd suggest net > - it's more likely to get tested over there. > That was one part I wasn't quite sure about - the v3 patchset makes things less clear even, since while v1/v2 are mostly mm heavy v3 would have some significant changes in both subsystems. I'm open to whichever is the "right" way to go, but am not currently certain which would be. Thanks, -Arjun > > > > ... > > > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > These changes could be inside #ifdef CONFIG_NET. Although I expect > MEMCG=y&&NET=n is pretty damn rare. >