Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp1967298rwa; Sun, 21 Aug 2022 22:37:54 -0700 (PDT) X-Google-Smtp-Source: AA6agR6EMh10GxZLNnxkLK185/Q9NQd61qrtVCKYv4p72dWOW7iwGi4j+lrMPftRpeA2zXgN6jby X-Received: by 2002:a50:aa82:0:b0:445:dbba:6cb1 with SMTP id q2-20020a50aa82000000b00445dbba6cb1mr14980200edc.267.1661146673952; Sun, 21 Aug 2022 22:37:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661146673; cv=none; d=google.com; s=arc-20160816; b=MlCu51w5ftpaBMRd62hJFI/Bj7eBg8g/hsRRlnYmbVc9DSgQhsYUOwltS/mi9UYl8S p7lhdD+gUsgvdGSXrCCc4DX2YJYDXJIASWdTuz5D+KxYAL0u3ghW3QNoTz+qJ6WkT9nt b6ewItI2KEUyjYNMx1H8aXAusDqQI8iJhKmMOvKaNstp+5Gzo1ycLfnb+Qr/p990eLEP b83OVJ7lYqxplObYeuH5BhwUTHab/R2tt/lAua+ewzHuS0vM/+Nv6xwASBn6/wm6ytDw Y7CJwlJ7+An5bODUFgMlY/NYBEeUq5aweertPSt6yqeJeb5AAj8LlDRM/joCQu2jA/vt WA1w== 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=9XhZmihVWYtN8pqGhGwupTf+AWRqtf1YyaQ/pGiog9k=; b=oIxJvlkrIOO8UnyN6fBKctM1nCA7yFbUka9T0xw4dkIDXspyTy8ctmSzNkGwVWX1OW L10xedefBJaaQ85lBaI60guxWv8+U4lTaXDjW/MhCm2k8FfX9Xs/FFQu2NYz91LJFbJa HnJersSE+We/Ueo5clpJ3KAyE6sqYSFU1OEn8VoAmaxkFm3Bs0D03u1oYep731dzq4/e vAq4Q/FB+4oIcbRUJ8OGruMgfLo4oeL1I6YUW3Tc9JpQf7cCf7DEsRmUeCnxVFF+XOV9 y2J3t2KX0hNIiM3xoEYP5Jd0hzsGANjUDP1hX8mhatxd+ewOH+yRseIejdKFwm7fTORf Y2UA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=e4g+T2mM; 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 gn27-20020a1709070d1b00b0072ab4b5ffe5si10861022ejc.987.2022.08.21.22.37.28; Sun, 21 Aug 2022 22:37:53 -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=e4g+T2mM; 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 S232526AbiHVE7e (ORCPT + 99 others); Mon, 22 Aug 2022 00:59:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231694AbiHVE7d (ORCPT ); Mon, 22 Aug 2022 00:59:33 -0400 Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BA1124F0E for ; Sun, 21 Aug 2022 21:59:32 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id d71so8393287pgc.13 for ; Sun, 21 Aug 2022 21:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=9XhZmihVWYtN8pqGhGwupTf+AWRqtf1YyaQ/pGiog9k=; b=e4g+T2mMYZZcLZKVuyYTBE7KioYD6BNBNG1cLqDFZ5B9t0E6FIRD5EvbyAzLTCr3kJ rA6ZK7oCz9GEATt82qpw+2JFjAHNx6MWzrOEJkCcglpPUJI6hS1usRrjSP0PtvLaklzt 2SWFQW3etXo3F8BRQXjkvsEAD1xWTy3389fS+y8cwwh/ZpGZYzfVQV4mAVDrVneI1RKY LqoHhaNoGRAKG4D6abLWZ4z6qaxhraGCM7tcAmHqKNXwMFf8R6WZS65/KM+mSpunicvW NoZagRqgMyd0mx1A/gtNa8G0tjAlwmRM7GukYQSHxRJh5NrCaUN7Ht0Ligb/wX1I4ajV MSHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=9XhZmihVWYtN8pqGhGwupTf+AWRqtf1YyaQ/pGiog9k=; b=XGhtMBa40RzZ0BQUXPFPmha3bk1ULpICOBMu98uj3irAxw2ZnzUbcfYbmc6QX3XVc9 4jYe2hToojY6DAs4KgFU5HmldyYTINIoKl9enHLTaNv+hG3XyM/ufzQnjGM3JNbWU0qY HfeuD+twyR/XPxn7eJAryW4eKoQdfQIVKa+dpGalV2UNYfTNDt6YXtrwpAhPNg/Ql/zt /5rK7jI73XUTpb3niEe22I1q89w0Og5YfU6Bb/17EeGLAPIfq/ZUmktFy0z3OQMJOqxm XwdNoDEoHe6PJbu0b6mJwV4Qpx8ZpefJIYoYam9AqLG+HpadFP6Xbi4PPeiDCNGdEoG4 FCfA== X-Gm-Message-State: ACgBeo0N3Z+fP9fp+eQsszvF1EI91Pr0V0pUgvd3BjAPVMvmp09kufmg CAlH4RpFsZGyGESw7znk6YLzRHzLSGGMnoJ/Nun5cg== X-Received: by 2002:a62:6497:0:b0:52e:e0cd:1963 with SMTP id y145-20020a626497000000b0052ee0cd1963mr19195169pfb.58.1661144371422; Sun, 21 Aug 2022 21:59:31 -0700 (PDT) MIME-Version: 1.0 References: <20220822001737.4120417-1-shakeelb@google.com> <20220822001737.4120417-3-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Sun, 21 Aug 2022 21:59:20 -0700 Message-ID: Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields To: Feng Tang Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , "Michal Koutn??" , Eric Dumazet , Soheil Hassas Yeganeh , "Sang, Oliver" , Andrew Morton , "lkp@lists.01.org" , "cgroups@vger.kernel.org" , "linux-mm@kvack.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" 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 Sun, Aug 21, 2022 at 7:12 PM Feng Tang wrote: > > On Mon, Aug 22, 2022 at 08:17:36AM +0800, Shakeel Butt wrote: > > With memcg v2 enabled, memcg->memory.usage is a very hot member for > > the workloads doing memcg charging on multiple CPUs concurrently. > > Particularly the network intensive workloads. In addition, there is a > > false cache sharing between memory.usage and memory.high on the charge > > path. This patch moves the usage into a separate cacheline and move all > > the read most fields into separate cacheline. > > > > To evaluate the impact of this optimization, on a 72 CPUs machine, we > > ran the following workload in a three level of cgroup hierarchy with top > > level having min and low setup appropriately. More specifically > > memory.min equal to size of netperf binary and memory.low double of > > that. > > > > $ netserver -6 > > # 36 instances of netperf with following params > > $ netperf -6 -H ::1 -l 60 -t TCP_SENDFILE -- -m 10K > > > > Results (average throughput of netperf): > > Without (6.0-rc1) 10482.7 Mbps > > With patch 12413.7 Mbps (18.4% improvement) > > > > With the patch, the throughput improved by 18.4%. > > > > One side-effect of this patch is the increase in the size of struct > > mem_cgroup. However for the performance improvement, this additional > > size is worth it. In addition there are opportunities to reduce the size > > of struct mem_cgroup like deprecation of kmem and tcpmem page counters > > and better packing. > > > > Signed-off-by: Shakeel Butt > > Reported-by: kernel test robot > > Looks good to me, with one nit below. > > Reviewed-by: Feng Tang Thanks. > > > --- > > include/linux/page_counter.h | 34 +++++++++++++++++++++++----------- > > 1 file changed, 23 insertions(+), 11 deletions(-) > > > > diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h > > index 679591301994..8ce99bde645f 100644 > > --- a/include/linux/page_counter.h > > +++ b/include/linux/page_counter.h > > @@ -3,15 +3,27 @@ > > #define _LINUX_PAGE_COUNTER_H > > > > #include > > +#include > > #include > > #include > > > > +#if defined(CONFIG_SMP) > > +struct pc_padding { > > + char x[0]; > > +} ____cacheline_internodealigned_in_smp; > > +#define PC_PADDING(name) struct pc_padding name > > +#else > > +#define PC_PADDING(name) > > +#endif > > There are 2 similar padding definitions in mmzone.h and memcontrol.h: > > struct memcg_padding { > char x[0]; > } ____cacheline_internodealigned_in_smp; > #define MEMCG_PADDING(name) struct memcg_padding name > > struct zone_padding { > char x[0]; > } ____cacheline_internodealigned_in_smp; > #define ZONE_PADDING(name) struct zone_padding name; > > Maybe we can generalize them, and lift it into include/cache.h? so > that more places can reuse it in future. > This makes sense but let me do that in a separate patch.