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 09EC2C43334 for ; Fri, 1 Jul 2022 15:47:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9293B6B0071; Fri, 1 Jul 2022 11:47:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DA036B0073; Fri, 1 Jul 2022 11:47:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A0BF6B0074; Fri, 1 Jul 2022 11:47:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6A0896B0071 for ; Fri, 1 Jul 2022 11:47:42 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2FFF1204C0 for ; Fri, 1 Jul 2022 15:47:42 +0000 (UTC) X-FDA: 79638961164.17.B48928A Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf16.hostedemail.com (Postfix) with ESMTP id B6A5218006C for ; Fri, 1 Jul 2022 15:47:41 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id a15so2788716pfv.13 for ; Fri, 01 Jul 2022 08:47:41 -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:content-transfer-encoding; bh=9yv6QUWYDmgQjKt1P93gNeGHmUq3W/So/sIQeZFHIcA=; b=rqzfXCul7tw0OtYOnP55pVCB7g/W9r+ESLzhXTbbeXFyAb7FsPVhGwWf1o6kj4AEw9 yy5yMHnLr97j5o8rrLFjKXtvNiVn9FBMx+OuaStaeI4VtIuzSQQMCYCKdG/m5/+ZvbtJ mgVJXlM7Ih3nxS4V9lsQKs/m0R9tyRektkxlV6RlzNAGVnt03mZ7EX5LY/pDnGeggzJW 5yhjTlYGbhC7Tjeh7iltQpmTBPc0/ob4Ek3moFpXstDBXYsgrX+l1Ee4H94nhyirr8kt PXIyVeGHxqvtHBp9W92BVREWrxfsXLcvqjppHbdeBuO4CTDShzDE2h5XITLVdfm3eTZi 0t7A== 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:content-transfer-encoding; bh=9yv6QUWYDmgQjKt1P93gNeGHmUq3W/So/sIQeZFHIcA=; b=h13wGy7AqVt3Aym2BMyVDnw2QJxmy7pYp/O6y7rXJRJBV6TbVwjizfVn0NUNqTWpe5 4jhoavFXfpUX4b7D2ctWSaSPR3cTs/e1eONcYeEV0FL39imNO7aXW+Y+iYVHKrxhhJcI dIcu4nRNpe96fy99Os/hoCKEyKuPRk5A0FtXMQPIagqWg2pvYXG2jRzaq3TMtHyCN+rb pT4Uu+K7kEr4nF3f5y7tcW1wliq0tRhbLlUV+bl3TS8CBwrcYftXVUM4LWGt3sYs/Q71 GLvYwyrO/X7umhlcg719+8/74MM8mltEBcrZPb0rdQoJbFTsLvivFb0fxQMd9WEXkulE 4tig== X-Gm-Message-State: AJIora933AWmxFVL2j7vfCNtdkQ8zV9xpYqH23lEOftjB6hLD424iljP pf1WXfsnor9GRxEikk6Zifh81DNGgQOj3ko0Soq8tg== X-Google-Smtp-Source: AGRyM1vA2J1Zo47ff1Z3g/0fDruleRJpKHeRmLkW3pftAi7eIEd7S1S7hhAlQL2NFpy1Yupar9lBK8glaB0jqxoYpPM= X-Received: by 2002:a05:6a00:3307:b0:527:cbdc:d7dc with SMTP id cq7-20020a056a00330700b00527cbdcd7dcmr19540188pfb.85.1656690460501; Fri, 01 Jul 2022 08:47:40 -0700 (PDT) MIME-Version: 1.0 References: <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> <20220628034926.GA69004@shbuild999.sh.intel.com> In-Reply-To: <20220628034926.GA69004@shbuild999.sh.intel.com> From: Shakeel Butt Date: Fri, 1 Jul 2022 08:47:29 -0700 Message-ID: Subject: Re: [net] 4890b686f4: netperf.Throughput_Mbps -69.4% regression To: Feng Tang Cc: Eric Dumazet , 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" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656690461; a=rsa-sha256; cv=none; b=Amq3xw12feib2DeaOS/UirjQHNY/Z5VMZBvsWtiI3wWZ6s9KSRvScoaMDsRsqGSufGCzqP vD5otIgUXaGz0Fd9aQ3ZGhWMdzzQyZfdCyume160PPgP+xmFEKyD0Nd09PNSPM2rZKazU6 AQdSRRK2SDbHD37SKmcYkr89R9MsJ98= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rqzfXCul; spf=pass (imf16.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656690461; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9yv6QUWYDmgQjKt1P93gNeGHmUq3W/So/sIQeZFHIcA=; b=WQmxtpIoaC9WDC5f5n1sVUQMPb7JztFGLu/GkKxUGO7s5no77050Tpel1J79xYtGP9av6T s3ZRx37Ygvqn4iCe+dxn2g/AIzpBmAgw2tzjelINgsebhdTiJnLdd8DF/sQdjn1Ydra1Dh bGvUWjGN1WwnQjez4wCE0eWeJceEPGU= X-Rspam-User: X-Rspamd-Server: rspam04 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rqzfXCul; spf=pass (imf16.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: szfn6iw8xkkdz5j4e537gcj8ck1s983u X-Rspamd-Queue-Id: B6A5218006C X-HE-Tag: 1656690461-506499 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 8:49 PM Feng Tang wrote: > > On Mon, Jun 27, 2022 at 06:25:59PM +0200, Eric Dumazet wrote: > > On Mon, Jun 27, 2022 at 4:48 PM Feng Tang wrote: > > > > > > Yes, I also analyzed the perf-profile data, and made some layout chan= ges > > > which could recover the changes from 69% to 40%. > > > > > > 7c80b038d23e1f4c 4890b686f4088c90432149bd6de 332b589c49656a45881bca4e= cc0 > > > ---------------- --------------------------- ------------------------= --- > > > 15722 -69.5% 4792 -40.8% 9300 = netperf.Throughput_Mbps > > > > > > > I simply did the following and got much better results. > > > > But I am not sure if updates to ->usage are really needed that often... > > > > > > diff --git a/include/linux/page_counter.h b/include/linux/page_counter.= h > > index 679591301994d316062f92b275efa2459a8349c9..e267be4ba849760117d9fd0= 41e22c2a44658ab36 > > 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; > > 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; > > }; > > I just tested it, it does perform better (the 4th is with your patch), > some perf-profile data is also listed. > > 7c80b038d23e1f4c 4890b686f4088c90432149bd6de 332b589c49656a45881bca4ecc0= e719635902654380b23ffce908d > ---------------- --------------------------- --------------------------- = --------------------------- > 15722 -69.5% 4792 -40.8% 9300 = -27.9% 11341 netperf.Throughput_Mbps > > 0.00 +0.3 0.26 =C2=B1 5% +0.5 0.51 = +1.3 1.27 =C2=B1 2%pp.self.__sk_mem_raise_allocated > 0.00 +0.3 0.32 =C2=B1 15% +1.7 1.74 = =C2=B1 2% +0.4 0.40 =C2=B1 2% pp.self.propagate_protected_us= age > 0.00 +0.8 0.82 =C2=B1 7% +0.9 0.90 = +0.8 0.84 pp.self.__mod_memcg_state > 0.00 +1.2 1.24 =C2=B1 4% +1.0 1.01 = +1.4 1.44 pp.self.try_charge_memcg > 0.00 +2.1 2.06 +2.1 2.13 = +2.1 2.11 pp.self.page_counter_uncharge > 0.00 +2.1 2.14 =C2=B1 4% +2.7 2.71 = +2.6 2.60 =C2=B1 2% pp.self.page_counter_try_charge > 1.12 =C2=B1 4% +3.1 4.24 +1.1 2.22 = +1.4 2.51 pp.self.native_queued_spin_lock_slowpath > 0.28 =C2=B1 9% +3.8 4.06 =C2=B1 4% +0.2 0= .48 +0.4 0.68 pp.self.sctp_eat_data > 0.00 +8.2 8.23 +0.8 0.83 = +1.3 1.26 pp.self.__sk_mem_reduce_allocated > > And the size of 'mem_cgroup' is increased from 4224 Bytes to 4608. Hi Feng, can you please try two more configurations? Take Eric's patch of adding ____cacheline_aligned_in_smp in page_counter and for first increase MEMCG_CHARGE_BATCH to 64 and for second increase it to 128. Basically batch increases combined with Eric's patch.