[mm-hotfixes-unstable] mm: memcg: fix struct memcg_vmstats_percpu size and alignment
Message ID | 20240203003414.1067730-1-yosryahmed@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-50787-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:9bc1:b0:106:209c:c626 with SMTP id op1csp779744dyc; Fri, 2 Feb 2024 16:41:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IH4nNxcfH6M0PMNlWD6/LWOUrLM6BoZalfbxzpdP/gyScncPdhM4XOWUTc/nknZfB/DwVBB X-Received: by 2002:a17:906:68ca:b0:a35:a9e8:b281 with SMTP id y10-20020a17090668ca00b00a35a9e8b281mr7859463ejr.69.1706920875396; Fri, 02 Feb 2024 16:41:15 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706920875; cv=pass; d=google.com; s=arc-20160816; b=gJY/oU9chnyncFoDzV4PNT6PFE3thYN6LhI8m1/PrvMg09xYNwDBgjpfNCGDhcq4cl EdCfM+xxWP0kgT3pysVgvZN0HF5OL/INjy2bk8r/Dw24GawFUqmNfJGuSj/JUtgc2oyx dN8D4McV0U0psUH9O1LDe6gCb8PIGKhi3gJf7TDPE/JcXVTisvCk22mpdOkUl6fdcKEX kISqLSXYHwK+w6B6Ld7zUvYyMKUoGeW4kQyKpvhv0iPHutcI/xXE6TM+ZlwyWQkwPquc 4F2qDTQexpbpkPaaAHiOT7tjBNjodicoVmxrKAMcLSjkgbkHbhhCUpVmT+XvbuYL73KN 2xrA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:from:subject:message-id:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:dkim-signature; bh=BCDzdkXKmcCm4b3zn1uKLp7BZ6kePV4TL8d+mF4c+RU=; fh=jtwS96HctFVRTY28aF3tij3GjO0Fry8KFkRnP4GEv+M=; b=eoiXxc15k1g1aOt4sqcmGNwmy/mm37HtD3w15TLzN2wVGrMjpF1DtqgSLV1gjU5CvY lHvU2M6ggy213t/ZnLGLisYqddpEhg7FgxCeMf09hODkZkFl7BGGfSTWPLSLBIaDTqHX 9HpW9QmqPVAv+Omtt9LWLAfFug2r488VQtPGlLsvhRjalcKO9/S7rz31gEr3OEj5kKnU IOVYlTzT1GzRspneCSgXHL26xOZZ973Pywe93pRTduAVW0n3CGuxphFzWtO0iOk6Osxn RqJMHqTTd2EuL9RrUL7tmpbripRTzcrN6AE5uK974M8vo3GedR5Yx6vFAi/Zqw7rgIH3 q09Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=IeAPXW0V; arc=pass (i=1 spf=pass spfdomain=flex--yosryahmed.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-50787-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50787-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Forwarded-Encrypted: i=1; AJvYcCUflKLRlIZEIZWSVDf6k9MY5q2Cl1wOAfGeVpvPYwdbYwk9rl4H7ee84yKjhxZDXxWFs2uYOp/FyuR1QuxMqd8bOFwigQ== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id e16-20020a170906505000b00a23619be213si1284324ejk.159.2024.02.02.16.41.14 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 16:41:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-50787-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=IeAPXW0V; arc=pass (i=1 spf=pass spfdomain=flex--yosryahmed.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-50787-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50787-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id A6B541F2BA72 for <ouuuleilei@gmail.com>; Sat, 3 Feb 2024 00:34:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5815C1C02; Sat, 3 Feb 2024 00:34:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="IeAPXW0V" Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D61D6FB2 for <linux-kernel@vger.kernel.org>; Sat, 3 Feb 2024 00:34:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706920458; cv=none; b=Iw6cJDKzpq6+aR5o4sUFMdIlWSEQPt0KxC85u3J+67uxC1ftF2qshyOKkIp4gBvXD5MTzTcbHnj/Zkk3k/fsH1Dt6hOCIVuFpKXDQH3C+mpArUIgeFS6CETtp9+Z87QJ/a+xPKsKHZmr8q5502JYwbnK7J4/AiyGkaimTCWEepE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706920458; c=relaxed/simple; bh=Z/cm2m18PsL8Vu1wWGOW1aO61N6+BbgnM41QboNb6Z0=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=W9KrZstmAu874AULxdxbIZ3RowsibHzLDF6NSnzbWN+GJYzkVXlaH9ReaGj+6RnTnDh0Cm7Wj8t46d2Q2VBzuqL1KYNItanvKbdV2eI9yzmQZDQWdiYd4BEvU19dgy1s01SjFTzv1oEtmFpvomVM1X7E9dFNLbcyUdaTK24nPKk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--yosryahmed.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=IeAPXW0V; arc=none smtp.client-ip=209.85.128.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--yosryahmed.bounces.google.com Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-5eba564eb3fso49236667b3.1 for <linux-kernel@vger.kernel.org>; Fri, 02 Feb 2024 16:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706920456; x=1707525256; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=BCDzdkXKmcCm4b3zn1uKLp7BZ6kePV4TL8d+mF4c+RU=; b=IeAPXW0VuvfS+wjiPjpLv4EX+pkt7nF/1G9Xrk/CuA8qsO3RVnx8Ab2dxNpI+IWjX3 9+W00wk+3rbi4v0p21xPZJcDqr14iP7/YXGdUTw+sK6UUDO9jukrZ6VPMRU6JNPfMRX3 TJHd+TyI7LWtyxAVjKX1UIG/+bddyHwaNwurbQ2DFfUCuUrFQxMvKwkVtm7allXaGF2a L4B4rZc530n0Wt2TDbynOrpWJsqSNuy3JiQSc8RM0BaXQhFSUCKkzfw9rH3dcWzfOXdE Jz+jC8uEb6vM4fxrt41EOe4KTg+PPU2vagp4VvjX4sgS5o6KJ6f9VLX2rXC4azD8L3Do n0BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706920456; x=1707525256; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=BCDzdkXKmcCm4b3zn1uKLp7BZ6kePV4TL8d+mF4c+RU=; b=f8ifr0odlGb8fcxQO6mEH860QSqixMUTw+p13tOy0tEOJrysIVXMAvdFTMqtMB4QMf jKoKy3naEyynBjoI6WPcJt3qpeyLHTqqbvBeOVceBxRkN+JsgJZbznsZJrNAOoJwxFNF +zcmKTybajOGsDUe3ZtYirjnPifclFETb57BNCWf48Dr8yiUvgdjGG3ZlTqcx04BYVyi n6ScxnRgw+505UFqDPkmEt34UmCVRYmWZLoPONh/7vlMupWgCPLv2y6SogMkeLnxP2WH ZziWBNjSpz1X0aA7d+ocBkNytrDorAetWzmc1P5pSILDj0062FVSnIEUNcZMdD7oAr0d b35w== X-Gm-Message-State: AOJu0YxMQJ8sjy/NOZOER9O6kUy4NeuP+xFW+wGli0pB9wrn3kTMaXov pqxgk5FW49YA891FQWf7Ce2FLBFMdiW3FLfNBIJybx6Bto4epFRVm0KaFNcwsCLIYAW/OGYhrwr 16huabVN9mwtRxr+atw== X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:29b4]) (user=yosryahmed job=sendgmr) by 2002:a05:6902:2192:b0:dc6:fec4:1c26 with SMTP id dl18-20020a056902219200b00dc6fec41c26mr37502ybb.1.1706920456138; Fri, 02 Feb 2024 16:34:16 -0800 (PST) Date: Sat, 3 Feb 2024 00:34:13 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> Mime-Version: 1.0 X-Mailer: git-send-email 2.43.0.594.gd9cf4e227d-goog Message-ID: <20240203003414.1067730-1-yosryahmed@google.com> Subject: [PATCH mm-hotfixes-unstable] mm: memcg: fix struct memcg_vmstats_percpu size and alignment From: Yosry Ahmed <yosryahmed@google.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>, Roman Gushchin <roman.gushchin@linux.dev>, Shakeel Butt <shakeelb@google.com>, Muchun Song <muchun.song@linux.dev>, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yosry Ahmed <yosryahmed@google.com>, Greg Thelen <gthelen@google.com> Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789836263924366837 X-GMAIL-MSGID: 1789836263924366837 |
Series |
[mm-hotfixes-unstable] mm: memcg: fix struct memcg_vmstats_percpu size and alignment
|
|
Commit Message
Yosry Ahmed
Feb. 3, 2024, 12:34 a.m. UTC
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 to
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_rstat_updated()")
Reported-by: Greg Thelen <gthelen@google.com>
Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
---
mm/memcontrol.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
Comments
On Fri, Feb 2, 2024 at 4:34 PM Yosry Ahmed <yosryahmed@google.com> 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 to > 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_rstat_updated()") > Reported-by: Greg Thelen <gthelen@google.com> > Signed-off-by: Yosry Ahmed <yosryahmed@google.com> > --- > 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_aligned; 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? I would say just remove the CACHELINE_PADDING() from the previous patch and we are good. 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.
On Fri, Feb 2, 2024 at 8:13 PM Shakeel Butt <shakeelb@google.com> wrote: > > On Fri, Feb 2, 2024 at 4:34 PM Yosry Ahmed <yosryahmed@google.com> 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 to > > 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_rstat_updated()") > > Reported-by: Greg Thelen <gthelen@google.com> > > Signed-off-by: Yosry Ahmed <yosryahmed@google.com> > > --- > > 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_aligned; > > 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.
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_aligned; + + /* Cached pointers for fast iteration in memcg_rstat_updated() */ + struct memcg_vmstats_percpu *parent; + struct memcg_vmstats *vmstats; + + /* The above should fit a single cacheline for memcg_rstat_updated() */ + /* Local (CPU and cgroup) page state & events */ long state[MEMCG_NR_STAT]; unsigned long events[NR_MEMCG_EVENTS]; @@ -632,16 +641,6 @@ struct memcg_vmstats_percpu { /* Cgroup1: threshold notifications & softlimit tree updates */ unsigned long nr_page_events; unsigned long targets[MEM_CGROUP_NTARGETS]; - - /* Fit members below in a single cacheline for memcg_rstat_updated() */ - CACHELINE_PADDING(_pad1_); - - /* Stats updates since the last flush */ - unsigned int stats_updates; - - /* Cached pointers for fast iteration in memcg_rstat_updated() */ - struct memcg_vmstats_percpu *parent; - struct memcg_vmstats *vmstats; }; struct memcg_vmstats {