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 A0477C4828D for ; Sat, 3 Feb 2024 04:23:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 317106B0075; Fri, 2 Feb 2024 23:23:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 29E316B0078; Fri, 2 Feb 2024 23:23:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 119036B007D; Fri, 2 Feb 2024 23:23:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id F083D6B0075 for ; Fri, 2 Feb 2024 23:23:25 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4864E120161 for ; Sat, 3 Feb 2024 04:23:24 +0000 (UTC) X-FDA: 81749198328.30.F5EA2B0 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf18.hostedemail.com (Postfix) with ESMTP id 571D61C0004 for ; Sat, 3 Feb 2024 04:23:21 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hYjQvknB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706934201; a=rsa-sha256; cv=none; b=hgp6Ofaiguhfu2QAGh/JL54v+VGn2zbK3B0epagdXAZqgC1hmDMEs8IObwl5xC7LNOjMgo 0Y2RcH8UaZwwjgBKK1zNJoRs+XnaDHx1dUqGo26FPQU5/CaVfL7xU5WkfrZBdFtXtx8rMk 7UpaEKPO31KmumqvF+uUEyukTd+p72U= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hYjQvknB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706934201; 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=DisFQpTn7TdXti+Sfq7OuBraM//Uzb0Fy3Abq9El6XY=; b=BUHH+9YBFX+jX4KxmDP+aj6dJ0JgzUfD/hbAEZTjdP1QICHSIWLvSdPTBV00kMF6ZypaWx zAF/CaHo08EWnOCcZtJSLU4efAq53XNgJM5JTn0QIF5/8fOaqyM1PE6l8mEz1iHy4KULTb gQUwi4cWUgNxXbe6beUCy4MT95hYFfI= Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-511234430a4so4667987e87.3 for ; Fri, 02 Feb 2024 20:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706934199; x=1707538999; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DisFQpTn7TdXti+Sfq7OuBraM//Uzb0Fy3Abq9El6XY=; b=hYjQvknB/3z0ySzos8cbVc/X2WdPGJLm2bLa2PThzAbQr/d2SyFYJMR6JIpTqOYIAX bqDiEfE0utj5zlLhrKzqLJUQMwdF3zYprm0E1sG7yp8SrMQ24BHOp1DVmxdBFRHLg7ud N3mSSVBqtFRuSK8DVtOcYGpZdLrBWjctuQL/7qQDKhwfiA/uff6aL1unwF2VW5j9Pf7Q bnaG0XuHCyTaYuf0xRadf/G2kPesJyVjd4+dkUeiHLQHSt9DFA9Na5Q8UFFPDKuyD6MV ZW2cdblzgT8AC45xtF2h8peV5JpMzkPplP/FhGJuimeeGpnkEqf8V2ZKPHvbGnug7WIX WOng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706934199; x=1707538999; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DisFQpTn7TdXti+Sfq7OuBraM//Uzb0Fy3Abq9El6XY=; b=jYiHV06vYajLPaeJ0hpIbC1EzUR8bKfhsSI5qUSTJiVHDuUdFwQ4fuwRTjl4gVn40X tghN5tOBR5szCOcRM+xZgXm2p46xbg5bQO4IPZzTpgSSQidpZOHvSN7kB21qKcXv4/Om eHw/RNfb41yOId0ae9YN9AndGFHJ8jEYWfyUnD+H5dUQbi77rHnrK5o+eDi1oFKKbaKk C8ztpoAzm0MFgpeG2yZ8wlttfSJ4596P3T0css4SIvyD/65uWf+JTJxOLWp9BtPSkN4c qKD1mT68MiMZO93/R97a3+JszG3guS8gqgZsME0dQ4Kq1kQzz1tpq143IKDIn7wLmJUg lUKQ== X-Gm-Message-State: AOJu0Yz1mEVtXKUc81tQs8brI84cIOAHUQ68jWFvoWlprddMfC3u/Wz4 sny+/xeJ3XNtHA7PwuRZSNlCXptARv+Si6KDhCamOx3JmTbRH+FdB3Q6nQWTyt2Obq1DXpJUQ4y Wc5Cvq7nZFBI8WHd/jHYfTRhq2zuu4AsXxPjw X-Google-Smtp-Source: AGHT+IFKvCQbNc+6dMkuI6Vjtw4TQbEk7zZdSVlZeVuzj7bG2ePVf9y2VMDFzBqSsBXRO+Xfzwu4RxFm8cRemMnTvVY= X-Received: by 2002:a19:8c5a:0:b0:511:320d:872f with SMTP id i26-20020a198c5a000000b00511320d872fmr3316565lfj.37.1706934199201; Fri, 02 Feb 2024 20:23:19 -0800 (PST) MIME-Version: 1.0 References: <20240203003414.1067730-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 2 Feb 2024 20:22:39 -0800 Message-ID: Subject: Re: [PATCH mm-hotfixes-unstable] mm: memcg: fix struct memcg_vmstats_percpu size and alignment To: Shakeel Butt Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Greg Thelen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 571D61C0004 X-Stat-Signature: s6tjn9jzr9kbbrdprs7i8fom1kasqp9i X-HE-Tag: 1706934201-525065 X-HE-Meta: U2FsdGVkX18XxefgvUDBcHiqpDoPZv921kphYt6hOjWSdc+SkCU06Ps604cLy+sHO4FuFeyKlsGg7P+jnXEY6W3utuRNGN+nQOH0ssjZKYrnmldLeDsj690UKxHgPKg/D8FL0/SC2xsg5gxoLu2r/2DA5OtPLoImP8noO6FMd+CLKFl7LRv9k7Lk429iJRWm2NRhvWyNO6bilHR/obSsCWxvmD3JDFism2tZhTpI9kp17EG+r5igJm4eJ4x8zvEjc4kOfiwSCycQqTQeuFh99Y2KY05qMVD1vfqRLzZYOPSOJmwDG5awff093l6Enz7CORbZ9fWc5PhHTi3EwB7NbCe6LT+bcdRtx4ie66CXF3mUPzDBEtbYoRbgpQzaQhJEIgPSBJHZ5Nqv8/0Qj6PXhAZj7YBs2WmEcf2PJmcblvrehrWwvtZmc26Le/ah2YrpawJTkYBHb1aTpmLJnOFa4V708Vp2hOQtZFaJkjFgbr01Q734G8Ci21/a7CflSkgcOEtaQxuzPZJp3mqgyqSX88p2r2kAt6PJeWmLGC+GDYtNBOorH0ILIwkrIy22SJekPiOU+d7uGa/pOwItjIWBAm7YOgVdSOgSkQWd2SXrFlSnz4GZP6O+uIsl7Qx62W8J3Bn0N33opfGcS2KWjxxBnxd3FqMCOI0LFGUS5ykulAU5+OehNEo50gJRM0JbrZt+QfL8Ki2KkRTNk9Wfb07kEdJTk4k0D3I7+XwDnkfvY2Xz9iHCy3HdLCJyE//sQhLVnJwtNMlW2m/IPpz4JfKirYcvAtuh8ef/DjgschrRqod+xpXcJS+PJCzDuIqnQvJ4W65WsaU8a+rUNdg12uMTImftFrC3COJ1oC7nEWGypl/Es3xeCSo8Yrftnf/girigBlTxdlhVBrJNkNZmv6rVzd1WlBHDnrhHUzriCAPSGkX5wKxSCvtiIvxVfYksAbETtLoEWZSVB6x813YgPuw tlWJKCa8 F4X3rsVVuJcdziup8ayYnLqONHN6dO1NNY5mXYVe8FeYITsbnG+EERNf/xDyT+IUPwHIBIILp+VkbIyixKq8FyXeH2DLeqh0izpDGD+PtzJMB11N9Ng7kzO+psD3nW+1o1bx4N3oqACeiVOrKI2NutgrhtT4x/tsK+hywuKJOKVmq/hxUACUyFd+4PmYPOZZ7mhjcPx0BMDVD5Y784Z7heUPGxLIayuaDtCPAhw/lEwln2wfokk70Jee5XiMR6ftYOHxqniIxOBKquSe+xzKPANMnIzcLkW03wsedpoJ45X02UuHViSmZSiL87mk36QjelUl2ce8PGayTqFI= 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: List-Subscribe: List-Unsubscribe: On Fri, Feb 2, 2024 at 8:13=E2=80=AFPM Shakeel Butt w= rote: > > On Fri, Feb 2, 2024 at 4:34=E2=80=AFPM Yosry Ahmed wrote: > > > > Commit da10d7e140196 ("mm: memcg: optimize parent iteration in > > memcg_rstat_updated()") added two additional pointers to the end of > > struct memcg_vmstats_percpu with CACHELINE_PADDING to put them in a > > separate cacheline. This caused the struct size to increase from 1200 t= o > > 1280 on my config (80 extra bytes instead of 16). > > > > Upon revisiting, the relevant struct members do not need to be on a > > separate cacheline, they just need to fit in a single one. This is a > > percpu struct, so there shouldn't be any contention on that cacheline > > anyway. Move the members to the beginning of the struct and cachealign > > the first member. Add a comment about the members that need to fit > > together in a cacheline. > > > > The struct size is now 1216 on my config with this change. > > > > Fixes: da10d7e140196 ("mm: memcg: optimize parent iteration in memcg_rs= tat_updated()") > > Reported-by: Greg Thelen > > Signed-off-by: Yosry Ahmed > > --- > > mm/memcontrol.c | 19 +++++++++---------- > > 1 file changed, 9 insertions(+), 10 deletions(-) > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index d9ca0fdbe4ab0..09f09f37e397e 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -621,6 +621,15 @@ static inline int memcg_events_index(enum vm_event= _item idx) > > } > > > > struct memcg_vmstats_percpu { > > + /* Stats updates since the last flush */ > > + unsigned int stats_updates ____cacheline_ali= gned; > > Why do you need ____cacheline_aligned here? From what I understand for > the previous patch you want stats_updates, parent and vmstats on the > same cacheline, right? Yes. I am trying to ensure that stats_updates sits at the beginning of a cacheline to ensure they all fit in one cacheline. Is this implicitly guaranteed somehow? > > I would say just remove the CACHELINE_PADDING() from the previous > patch and we are good. IIUC, without CACHELINE_PADDING(), they may end up on different cache lines, depending on the size of the arrays before them in the struct (which depends on several configs). Am I misunderstanding? > > In the followup I plan to add usage of __cacheline_group_begin() and > __cacheline_group_end() usage in memcg code. If you want, take a stab > at it. For now, I am just looking for something simple to fix the struct size proliferation for v6.8, but this would be interesting to see. I wonder how __cacheline_group_end() works since the end is decided already by __cacheline_group_begin() and the cacheline size.