Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3163907iog; Mon, 27 Jun 2022 10:26:35 -0700 (PDT) X-Google-Smtp-Source: AGRyM1smVSRODsGu0lygu53TdcQF74ZObGCb9WsHyWP8wVovk6NXaJo/5PBaCBalM5vR4sOUfiJD X-Received: by 2002:a17:907:7f0d:b0:726:2a87:b387 with SMTP id qf13-20020a1709077f0d00b007262a87b387mr13790212ejc.454.1656350795712; Mon, 27 Jun 2022 10:26:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656350795; cv=none; d=google.com; s=arc-20160816; b=x/lmmSA/FlRr+XZxc7OqnHBbY3bBk/Rf5ARIx2S/VN49rpDwOVHyjin/PWuXhXIxqr JogeHYLekvs+4Fo8TxxIlrCGQ6jMRr+GDKk3KukD2Xu2Ucyr9LcmX6dn71F5cH6GPWhB 3UJx6CQq/fUr4hnf9YAQ7SuDRSgGcUpg9U8xOqlteEvdyOjGRX7N2uBCZ6pFuYscx8gN n02bar7b0wGQFXsuZp/zZLGRCF7FUdr1n95/eD0SDulY8C1sTZOR/9v2ovQ7TyCusDpS aM++XB/a7dH6YdAsoVsU/THsISe1tIMDkCyotTkSiYfBFIfNXoDAbAuIU/LWjuw2cDYX 2cpQ== 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=D9X7Baf6YEccScfwTHV2+DoPAKr+D06FDzhDesIrDHU=; b=lyeiSAKlWExAEx1WeojtmQV9t4Qfz3GrCG/wWBvDNjFnCyI/axxv2Tc1yzJ08610NX Fd5ks9b4Mx+I4LSrrkkNpHBtcfRT3GnZadK3M9ST0tjB51Jz5W/yGLyDlT9LwL+YSNEh gptWDJqyN0RjgrfbsxfoA9xpF6mE17iVmCqJZ6PX6XEBCKtVPFmNEDZffV/jWk5pA1HA 9fBcWurSfjcBF94xnuQAXmrh8BspAvt7C1MnKzqT3MzToz31G3hC+Wl7VFmxZherA23K Nyx71GKeZOAqMVcVCGSesJxCKg++VSG/6XXPsdzUSx+lrSKB1zuG41r/U3Cm7JKSBpIp KN0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=TY2iLMl+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 20-20020a508e54000000b004356c0fe56csi11113828edx.553.2022.06.27.10.26.11; Mon, 27 Jun 2022 10:26:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=TY2iLMl+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S239589AbiF0QsP (ORCPT + 99 others); Mon, 27 Jun 2022 12:48:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235192AbiF0QsO (ORCPT ); Mon, 27 Jun 2022 12:48:14 -0400 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14F0EC00 for ; Mon, 27 Jun 2022 09:48:13 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id t21so9574317pfq.1 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=y7j7pl7fUxLMTbGVFbWfsss380EiYJPwCAa68XHEN7SYJUT7bgy69GQ+ntlO8WZViM 9OIPp9xcRf5Ow2q13UhgPQ52rICISyoEFWaylXxYd/RunxRPX/h5wyciVFUtQ7Tzy9Aq Y3l96MQQb6ZLB652dY8bKRb17lGz+IS9rOOrWarNtg0uo6bHyMPgttcee6MTnm+uMG26 zx5eo4H7ZKHZblVSeWFvv+8zzDZAb/Q3DColKDEf89BHdojosYGzRoX4s35SbjJv2+VO 6btJj4uKyZRzWkmpDDdPbkr72Ys8Jt3CIfaOVXakyBobqROw2MNGsmbxpOrig//m1TEQ Sw0A== X-Gm-Message-State: AJIora+i+gPFTWtYBBsxYdZWhp7XlAoVBBaQkPfV+wP8hcdkJH7l+yvx P6cSHher7mtAxTAG0lVXxwKLI3xjdExXQjDvYS49hw== 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" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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; > }; > > >