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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 384D6C43334 for ; Mon, 27 Jun 2022 16:48:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C65468E0002; Mon, 27 Jun 2022 12:48:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C14DD8E0001; Mon, 27 Jun 2022 12:48:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ADD1F8E0002; Mon, 27 Jun 2022 12:48:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9F3EB8E0001 for ; Mon, 27 Jun 2022 12:48:14 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 775BE120EF9 for ; Mon, 27 Jun 2022 16:48:14 +0000 (UTC) X-FDA: 79624598508.07.8915E1F Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf23.hostedemail.com (Postfix) with ESMTP id 93F33140028 for ; Mon, 27 Jun 2022 16:48:13 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id 128so9524291pfv.12 for ; Mon, 27 Jun 2022 09:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D9X7Baf6YEccScfwTHV2+DoPAKr+D06FDzhDesIrDHU=; b=TY2iLMl+iHQtwwgqdID5GGR/WgTM934LvGgTG5bdqshKdHchwFWk1/f7YcudfG28C1 9svXGsq3ZBUdpFHkuir48kWdUp3+pk7zV9uR3pX3gssgb3g7T4Uld0Y5GC+YNwjiyyUi JaQ614mZjho9lPRJILtdry1rGOBttSD/YqxwDAQgnUoUa0wg4Jg73a4zXCRzF1KjrIyd 6WOLmF0GeKCQ+uyS14AIDBC8y9PCeYTPXlWFWNAlUpXJJxnaFWk41qgGu1NyepGq/BCn rOr2Kt4QaK+ajKmOKpIMCnONrGRHdxChGIF3ol6MkzFrpF0tJ1PFYirMMNa2s5PESFwE xDIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D9X7Baf6YEccScfwTHV2+DoPAKr+D06FDzhDesIrDHU=; b=Z8pxZdA79B1+eQ0ioLtoNfUrH8ZCoGNzmeM6jqoCQhfyxl4Ft5aPlNtdXDS4UzA7yQ 9fa4e8c0Dm+9QqOMvli54cSxvpeBMLR8/vduAKcgL37ac56LQyGHqL8KHGKlg2z+Y7LC nDYebPjMWmwJRwjAsWLLKNnqhpNKirKL8BajjcUWxkt8/YPUCAl84paPEPfH7gG9OXSE 3vw0loovaNJNZusZCkJVwRObxe4skiV/Uo61hglfUJJUFhxovRuEQ3J7p0rPQkSlEt0N FgJvbeU0y5PQN93pbIEje3AEh5l9XCGg5noEi2zoH0cD+jE08ABFKU2bhIiHYJQVDaVz cHzg== X-Gm-Message-State: AJIora+8cL0s0DBuLHB+dckLyYRR7xUmAoqSdUGnXdE68hKsTRRYvNKo DXziwvJNvfTZdHFucy25F/M4cfrazoyeayJl5Fmk5A== X-Google-Smtp-Source: AGRyM1towA5pHVttt57ZXcLFZBHO5p9LUL8cqF9G7ljmFR23cWoIMilVj+6dSITeXoJrr0H4tquCuyHDp9ibcsb2nz8= X-Received: by 2002:a63:6cc8:0:b0:40d:e553:f200 with SMTP id h191-20020a636cc8000000b0040de553f200mr6817388pgc.166.1656348492366; Mon, 27 Jun 2022 09:48:12 -0700 (PDT) MIME-Version: 1.0 References: <20220623185730.25b88096@kernel.org> <20220624070656.GE79500@shbuild999.sh.intel.com> <20220624144358.lqt2ffjdry6p5u4d@google.com> <20220625023642.GA40868@shbuild999.sh.intel.com> <20220627023812.GA29314@shbuild999.sh.intel.com> <20220627123415.GA32052@shbuild999.sh.intel.com> <20220627144822.GA20878@shbuild999.sh.intel.com> In-Reply-To: From: Shakeel Butt Date: Mon, 27 Jun 2022 09:48:01 -0700 Message-ID: Subject: Re: [net] 4890b686f4: netperf.Throughput_Mbps -69.4% regression To: Eric Dumazet Cc: Feng Tang , Linux MM , Andrew Morton , Roman Gushchin , Michal Hocko , Johannes Weiner , Muchun Song , Jakub Kicinski , Xin Long , Marcelo Ricardo Leitner , kernel test robot , Soheil Hassas Yeganeh , LKML , network dev , linux-s390@vger.kernel.org, MPTCP Upstream , "linux-sctp @ vger . kernel . org" , lkp@lists.01.org, kbuild test robot , Huang Ying , Xing Zhengjun , Yin Fengwei , Ying Xu Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=TY2iLMl+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656348493; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=D9X7Baf6YEccScfwTHV2+DoPAKr+D06FDzhDesIrDHU=; b=ca3/vUy7VYz6ecC1vTcEa8GJZ6+YNg0Hxo/Fy5etXD8BCE1OyNZVt0ZyIEK+76D6OcPozV /mr6V8FXEt11MB6dAIuumemFpuqV3t7RhF3aIUxVubqIODPpXpLF2qcArYPMnmeTSCFg0K m5zwIPYjFYX/21QhPDm9b2868GqUXqg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656348493; a=rsa-sha256; cv=none; b=ON5XTYm+mylH0Pg0dUFf3XWE+U3m+UJgnrvQul8NAfrQxqPjYZA8Wt7i1rKWIImlkaJFW2 MuQ4uJxcqIoYlxZf14jLeciMAReqRsN59GTEhC8YNY4LvIvmuusRpKyzyWsoHhRsQ9WA2w ZfTn5JQvSnHaJpNywXzlOcmhyzfSAZ8= X-Stat-Signature: yh56csojww59mfqx86gr4tcqowyt8msa X-Rspamd-Queue-Id: 93F33140028 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=TY2iLMl+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspamd-Server: rspam12 X-HE-Tag: 1656348493-449587 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 Mon, Jun 27, 2022 at 9:26 AM Eric Dumazet wrote: > [...] > > > > I simply did the following and got much better results. > > But I am not sure if updates to ->usage are really needed that often... I suspect we need to improve the per-cpu memcg stock usage here. Were the updates mostly from uncharge path or charge path or that's irrelevant? I think doing full drain (i.e. drain_stock()) within __refill_stock() when the local cache is larger than MEMCG_CHARGE_BATCH is not best. Rather we should always keep at least MEMCG_CHARGE_BATCH for such scenarios. > > > diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h > index 679591301994d316062f92b275efa2459a8349c9..e267be4ba849760117d9fd041e22c2a44658ab36 > 100644 > --- a/include/linux/page_counter.h > +++ b/include/linux/page_counter.h > @@ -3,12 +3,15 @@ > #define _LINUX_PAGE_COUNTER_H > > #include > +#include > #include > #include > > struct page_counter { > - atomic_long_t usage; > - unsigned long min; > + /* contended cache line. */ > + atomic_long_t usage ____cacheline_aligned_in_smp; > + > + unsigned long min ____cacheline_aligned_in_smp; Do we need to align 'min' too? > unsigned long low; > unsigned long high; > unsigned long max; > @@ -27,12 +30,6 @@ struct page_counter { > unsigned long watermark; > unsigned long failcnt; > > - /* > - * 'parent' is placed here to be far from 'usage' to reduce > - * cache false sharing, as 'usage' is written mostly while > - * parent is frequently read for cgroup's hierarchical > - * counting nature. > - */ > struct page_counter *parent; > }; > > >