Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp82969rwe; Wed, 24 Aug 2022 17:33:47 -0700 (PDT) X-Google-Smtp-Source: AA6agR4mnE2aElaaADGOi0cNPZhYsaeQ/vn3HDqh4P2sEXUdRjbMLwvax/BrSX6Hhjt1pEmHQt4P X-Received: by 2002:a63:d448:0:b0:41d:d4e9:b4aa with SMTP id i8-20020a63d448000000b0041dd4e9b4aamr1113388pgj.123.1661387626879; Wed, 24 Aug 2022 17:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661387626; cv=none; d=google.com; s=arc-20160816; b=zIHKT3nam6VRBBFD+hSV0TOLGi0EWqocUZAuvdrOophFNTphRlWsyNeB+Tmdzwv4Ne fJtx7wwj49IClSjSf+cTbC/MNGxBaM64kk/YRKxlVBaoHrd3pbYA2BtHlRTr+D7oNDS4 JwxPXEuqTEYFGYiWb/Qv59fkfopE8suXykpSwdAsdr16xMj4p9nZjma7LsmjFwqdj7gu pAo1x/p8nEoMDt9d/OnOdNcPtB2m/xOZbB1So04WZVT/obIhXv0BvAC+lrcJeT/EqK4f nOzhZcBdHXfBCJeodDjfNGr0t2ySjNLFvJVkW8S2e3NK5b+bR0+OT143lawV3yW0nJMu n3gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:dkim-signature; bh=PYwH6PVPNEHbvaxrK4rS2xJuwZB9u4thO5MZW7XvPbI=; b=QjQMVf7IFL8hJqkX5uMoUsBeVFuit5ij/rgyo0oPyW60t3qmptKKY/oJUkXvxPJVrJ RCU07ZAmo5QwyETOaZW1qGSCm9O7OGbZs9GOkJa4CYlVgU/cpZuZW1eU4F8kap04L8dl 7vDIYEjxNcgdpRvWKuOJw0oKjIwJrX9C+6La+5/OY2pZ6pzqRLKMAgtoprHH332sZsd+ Cvc87rQJdxx4qyzjuLTP+8h8wxWaXZhGTl43ke3iLWQePJghm9leqCSJJo+W4koy0Vdd o4axNYPJpDlb8Oev/5TWauAOqVyS54EJ9+7oWBfjKwKs05WZs3Py5rMG45pLd7MhnpA6 oLIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=P+EUKtE6; 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 na5-20020a17090b4c0500b001f021b4f1d5si2919850pjb.1.2022.08.24.17.33.35; Wed, 24 Aug 2022 17:33:46 -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=P+EUKtE6; 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 S231547AbiHYAFr (ORCPT + 99 others); Wed, 24 Aug 2022 20:05:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230448AbiHYAFo (ORCPT ); Wed, 24 Aug 2022 20:05:44 -0400 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2BCC66114 for ; Wed, 24 Aug 2022 17:05:34 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id m24-20020a17090b069800b001fac361aec2so8072972pjz.4 for ; Wed, 24 Aug 2022 17:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:from:to:cc; bh=PYwH6PVPNEHbvaxrK4rS2xJuwZB9u4thO5MZW7XvPbI=; b=P+EUKtE6ricb8wdTGimfBl8wJsULmlf1U1ls8bGlVkUaNforVbvQ3tC93r2Tpdhx/X hu4ZaMawAO1E12zWi9v+4nP6DUb1SVdPpLc3AZ/xudS37LWaRSiaGz4e0Ka35xNar8nS etTkXsMGtCUsHLIDJkq4yN6bXebVUWkeBXO36LV/lhjXudjbUt/w2JGO2qgaytESq7HV 6902pIR1fNvHv7YRbB2LtQuxsm8du6S+P2rMcQlo6xTb/H6Yi7+CtEya63vTqQFwHjtL G+IvhJMvzorYcD57EwbY2fI611avPsNj/SezAfStYMECqaRueXSKqxPmfC43aGfBG3ct BUhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:x-gm-message-state:from:to:cc; bh=PYwH6PVPNEHbvaxrK4rS2xJuwZB9u4thO5MZW7XvPbI=; b=LKucaJUc+jCYwi91JVG4OSX3hJQ+Wf59HrQ12528DeKPjVaNtabarlcm7Biq6NqH44 LgtH/3RCW0sMD/DvZjwRacJF2H0JU8yvTbSkIW0JDFKnsaZmzjbT0PJnlqfBRzPBHMPP BV9f5BDsZofpl+hWmORITKEsL3IPOwiV5eKkiEMYgAGgIfwJ+LZRZbuke0D/s3OSvYjy ByjLbCtg+vUtdAS1p0C3DI5BZBA18XnRJC237HMULECJLL2b40wq5oDkl4vufOzENiYE 84MW/EMPkmzsW7J3YnfWYxeV9/jYVFQlhRptBuu1m7AE7C6tKIt4Fh0vR7swAoTa9q80 lGow== X-Gm-Message-State: ACgBeo10ug0RwfPyaan7A6xsp4BqS8PjK1Imny5yTYhd8d4n3xY3aRmg O5Ugls2NQr+GaNcolZLfNHUYfPn0Cm4jjw== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a17:90b:a14:b0:1fa:bc6e:e5e8 with SMTP id gg20-20020a17090b0a1400b001fabc6ee5e8mr118633pjb.1.1661385933916; Wed, 24 Aug 2022 17:05:33 -0700 (PDT) Date: Thu, 25 Aug 2022 00:05:05 +0000 In-Reply-To: <20220825000506.239406-1-shakeelb@google.com> Message-Id: <20220825000506.239406-3-shakeelb@google.com> Mime-Version: 1.0 References: <20220825000506.239406-1-shakeelb@google.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog Subject: [PATCH v2 2/3] mm: page_counter: rearrange struct page_counter fields From: Shakeel Butt To: Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song Cc: "=?UTF-8?q?Michal=20Koutn=C3=BD?=" , Eric Dumazet , Soheil Hassas Yeganeh , Feng Tang , Oliver Sang , Andrew Morton , lkp@lists.01.org, cgroups@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Shakeel Butt Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_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 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. $ 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. For example with this patch on 64 bit build, the size of struct mem_cgroup increased from 4032 bytes to 4416 bytes. 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 Reviewed-by: Feng Tang Acked-by: Soheil Hassas Yeganeh Acked-by: Roman Gushchin --- Changes since v1: - Updated the commit message - Make struct page_counter cache align. include/linux/page_counter.h | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h index 679591301994..78a1c934e416 100644 --- a/include/linux/page_counter.h +++ b/include/linux/page_counter.h @@ -3,15 +3,26 @@ #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. + */ atomic_long_t usage; - unsigned long min; - unsigned long low; - unsigned long high; - unsigned long max; + PC_PADDING(_pad1_); /* effective memory.min and memory.min usage tracking */ unsigned long emin; @@ -23,18 +34,18 @@ struct page_counter { atomic_long_t low_usage; atomic_long_t children_low_usage; - /* legacy */ 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. - */ + /* Keep all the read most fields in a separete cacheline. */ + PC_PADDING(_pad2_); + + unsigned long min; + unsigned long low; + unsigned long high; + unsigned long max; struct page_counter *parent; -}; +} ____cacheline_internodealigned_in_smp; #if BITS_PER_LONG == 32 #define PAGE_COUNTER_MAX LONG_MAX -- 2.37.1.595.g718a3a8f04-goog