Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp2523958rwa; Mon, 22 Aug 2022 09:02:50 -0700 (PDT) X-Google-Smtp-Source: AA6agR5s0synN/ALnmxWtIsQyr/CsAWp4Jz+cVXMxiG6gH1CFpG5BBjOwrU/KreQvuA4d3YyC/9y X-Received: by 2002:a17:90a:dc15:b0:1fa:c517:7f14 with SMTP id i21-20020a17090adc1500b001fac5177f14mr25286729pjv.117.1661184170681; Mon, 22 Aug 2022 09:02:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661184170; cv=none; d=google.com; s=arc-20160816; b=S5L6JKwe1BizCA/tD9CaewPooCnHU46bSW039/+MIQ/7OuDK0R1zvlzgIgtsc5jkh/ 2377oDLMPPbybikdShC3KVVAJb7z2juw/F/px+EVFPLElCbRYYbu5VN+XruS5uPjeVpV qIItcQudnxVqhVGjGZIU1AQO69aX53jDZKnKsidW7C/uCuWz0dwlzffLk7f6WaUv31MG 87OB7OW3mQhFeqHmJ6qd6AQ+3b9O9nG3gvr0FQdyUovTHpRIStAxrO4SXLYswmMrUFI2 8NQ+kERDPgL8JHkh3MiHqYSPJih5DogUeiBr5P/JL8b1PKCI82UAKLfzEOlSttRubXHt aqrQ== 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=rfnLOnYHfibKVs6Fb4CyKhxW8tJzjkgGwDzJoC+bA0Y=; b=SfcjbdJa9m55LYH1AV6TTZ/WrrfC1m8i5rAZpZfjbUpNgPN8jTSz+9YVMQbCeAAOko vN3xsyjOAfYSsNzmyANF2vWmnCew5g8Cdc/Kqi+FqWbN0l3XqhzjaoGUTTUn5N5u7Mc+ H5beCKnEAZRxg4qgyYUy7gAg57yknlejGKJeiZS+8+AqQjvfESSPJnHaJmBnFv/Fvhz+ a84MxVPTiMnvdlkuZ7nNp1IGkMDkJdcZFtw40pKZ/mg9g40Cg/HgL9hrgPRwujY4KgVT Mi8Awp95Ge1oB7eF3CqJVzoeUbWJvhKWR3XDAGUy6hn5k3dVku9nDZ9BlidMK3AuKq06 ZwNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=WrEDmTe0; 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 189-20020a6302c6000000b0042a5e9b8da7si9386399pgc.626.2022.08.22.09.02.35; Mon, 22 Aug 2022 09:02:50 -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=WrEDmTe0; 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 S236077AbiHVPI2 (ORCPT + 99 others); Mon, 22 Aug 2022 11:08:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236102AbiHVPII (ORCPT ); Mon, 22 Aug 2022 11:08:08 -0400 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AAB8F3B96C for ; Mon, 22 Aug 2022 08:06:30 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id 73so9608946pgb.9 for ; Mon, 22 Aug 2022 08:06:30 -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=rfnLOnYHfibKVs6Fb4CyKhxW8tJzjkgGwDzJoC+bA0Y=; b=WrEDmTe0u3FiZugr1PESRLE48S+q7XVC3UauDjAcW6HIAjvR0HdyDSvY4Yh8Xv56pD zPk2pcgIpSUnoaMXQGMFXbv7itfEgQxASZu3plwAPK03XvXa6lCQJD9NZXVJ5o1FBtB8 X3x7rF1QRsVh4MXlsOXYfj66zh30hHfyZ2JsCANksMqp18M7jGVX8W3hXJJrdalpRqiG suK5gjJfRKexqrQW/aKqFE+rYX7mOOZjjtfZCMzUoTVD8zZSvk9fiLVnIeZIGLgGzJaA dDSVJr3UUABWryrmO8Xl1VpIQ5ZWGOWL9XjGltxQGHICMF2l1LmnoW0euDwnBGjZS2e+ 1bmA== 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=rfnLOnYHfibKVs6Fb4CyKhxW8tJzjkgGwDzJoC+bA0Y=; b=YxiRWlzmxQtiLnp+Lu8vyap65yXLYbjvBB0N6CeX7uw/wf3YY5Wr7Ys5Ai/YfDLS83 rDvfNbbnAdNqWFOVr45XdOBpTgFmUtvhQQDcUIh/gTb9H/MH8U7susntAIu3Tw2QWkAK PHnMHM/cH4++SHZW9LbYl8Pz/Md19624dFfAOCpALpGHXZvLrO2aiVAUGOF6pCE9hnMk Bs1XxAervRsSjFMQ5E3xncuIumSq5FaNEUF2J7koZ8Isbe3SVw3sq2AXzrndj91wgFPd njs0DZd42VMEcq2kC19mCfLQruO8BqkcnzLiYA3FgDxrqVflfWsBDdY8dMY5FnCS6Z0N TZ5A== X-Gm-Message-State: ACgBeo2R9NqnVEManHAM4Lto1TB5LW4+QjDXCCh4mXRMQvS/2qcAu4JC Wei0rzz4lnp2qoAyxqs8tHHr4YiLEOGjEFbXNSXR+A== X-Received: by 2002:a05:6a00:2392:b0:52e:b4fb:848 with SMTP id f18-20020a056a00239200b0052eb4fb0848mr21499685pfc.8.1661180785557; Mon, 22 Aug 2022 08:06:25 -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: Mon, 22 Aug 2022 08:06:14 -0700 Message-ID: Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields To: Michal Hocko Cc: Johannes Weiner , Roman Gushchin , Muchun Song , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Eric Dumazet , Soheil Hassas Yeganeh , Feng Tang , Oliver Sang , Andrew Morton , lkp@lists.01.org, Cgroups , Linux MM , netdev , LKML 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=unavailable 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, Aug 22, 2022 at 3:23 AM Michal Hocko wrote: > > On Mon 22-08-22 00:17:36, 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. > > Again the workload description is not particularly useful. I guess the > only important aspect is the netserver part below and the number of CPUs > because min and low setup doesn't have much to do with this, right? At > least that is my reading of the memory.high mentioned above. > The experiment numbers below are for only this patch independently i.e. the unnecessary min/low atomic xchg() is still happening for both setups. I could run the experiment without setting min and low but I wanted to keep the setup exactly the same for all three optimizations. This patch and the following perf numbers shows only the impact of removing false sharing in struct page_counter for memcg->memory on the charging code path. > > $ 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 > > --- > > 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 > > + > > struct page_counter { > > + /* > > + * Make sure 'usage' does not share cacheline with any other field. The > > + * memcg->memory.usage is a hot member of struct mem_cgroup. > > + */ > > + PC_PADDING(_pad1_); > > Why don't you simply require alignment for the structure? I don't just want the alignment of the structure. I want different fields of this structure to not share the cache line. More specifically the 'high' and 'usage' fields. With this change the usage will be its own cache line, the read-most fields will be on separate cache line and the fields which sometimes get updated on charge path based on some condition will be a different cache line from the previous two.