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 85529C4345F for ; Fri, 3 May 2024 10:18:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ADE866B0092; Fri, 3 May 2024 06:18:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8F556B0093; Fri, 3 May 2024 06:18:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 956126B0095; Fri, 3 May 2024 06:18:25 -0400 (EDT) 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 744D36B0092 for ; Fri, 3 May 2024 06:18:25 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1EB501210B6 for ; Fri, 3 May 2024 10:18:25 +0000 (UTC) X-FDA: 82076684970.01.087C961 Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) by imf30.hostedemail.com (Postfix) with ESMTP id B5A048002A for ; Fri, 3 May 2024 10:18:09 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cZOh6Kv5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.50 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714731489; 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=YOCxihFTZ93q9UGZxwfGJW39u3GtAUTg2XU6hUmy/Z4=; b=vM1Yh/laoj2AN89WRi1ZNaT7hh9KTMvody76tYh8WiWjefmWh1ZEShscbMqEfebXE4rgEN ZMpTw65KZbIQLLGQGDDfXN6AmZA6G7kAJTKiYvt+yiOB+BZCcaeA5ZWN/tLqbikVSl78ml pAHCpPWOpg1uVqj9GxFqnns4pUq5a48= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cZOh6Kv5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.50 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714731489; a=rsa-sha256; cv=none; b=qAeR4SPnt1Wx4YkTjvE2tV/hefbc3a3OiQvTw5KSz28fgJKcPdIqlFzcWtJLy/vcjwBek1 jI48KSR2CEynqc1QPM5S0Cq6/3xetl1ohhjtO8xZgRMqrXjfUxRStcIBADAllqL9MFS/d2 yHkjB58dbZ5PKnSBrvkzuMpLCNt3SAk= Received: by mail-ua1-f50.google.com with SMTP id a1e0cc1a2514c-7f18331b308so1237763241.0 for ; Fri, 03 May 2024 03:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714731489; x=1715336289; 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=YOCxihFTZ93q9UGZxwfGJW39u3GtAUTg2XU6hUmy/Z4=; b=cZOh6Kv5giH0ERTyIeqct/ozTrLBJJpBeUdlSdx2hSHMihKrc6xqfPFsGYDVqbRwlj D+mQt0gtEKWrYM7YdKmBwca4dI5vExqVFDi0lzHoyg+Y1o49+klDF6b9yQjS+QbnImyb kLm+I30chjRGQY6Y+59Zz6xYOe7qv1CLVFGTnnL2oyQN0uAELeXjIQpYharY4C+Aih2Y WRklDt2opNMzkMhYulUHab3Q2Xwr5cnbCZmA70ONNVMr2Uf8P9LNhq5lIZL7RhQZ6lHE 8pUbuUc/jkZ2fbGVSwPxplso6qGTUvKbY75ujdMrT9D4+/jhQ4PWBODRluF+z3k+S2cH 0dqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714731489; x=1715336289; 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=YOCxihFTZ93q9UGZxwfGJW39u3GtAUTg2XU6hUmy/Z4=; b=m9QvMghofT5RDaqNWvxa1jfsa5XSeU8zlz/XKxZLkleMZbfBgeTiWUC6sVMgbWlS/L xXq07Luhl0rM/871ADkUHTfS7p6HMGHPmR9xpJMkL4obyCQ4WBGNEoq09hPn0r+LKs4l 6c0FdOxE8/F1cmAkuzA8Z7BmOfHjm+xXDc2iOxmT49l5ODmTlAUP7297kpHJQPyBNCf8 IzXKbehOXeeEFDQDZ9txifQNLY09/4jM285YTHrB6OXyAgeAnRx52Q9JFO++2O6oSXah IF7IWGsRYe60ryJ9NBKVv1kBRjnxAsJPUlvsrSnC2uWNvdjx6GnG5sSqNUapCwT+xVcD A5Ww== X-Forwarded-Encrypted: i=1; AJvYcCWsPJTd400hsRWFY1xgedPDD3tNduJV8cr4dinw5tTmEXu4y+qHGV+2lD2xdDhxJShL7tGnR07M7dOHGWMokGakmv4= X-Gm-Message-State: AOJu0Yz7zQhMhFeMyoQ1eLhnXyfGnT78CvPOlHOIxHnwUgZD6/HIR+qD 1io07HHupC2+0cRe+qI7nSo1TWy3C8aRcXfal/sEf25PncKjfLpdS5TIAjMc6B4YsbzLtXu6Fte BvK5a8eFF5GNyD3TTTEPsVuWQOOI= X-Google-Smtp-Source: AGHT+IEj9v66eFqgfUMLdRmx/EmJgZY6G+pUj3Rf1mrK3BlE9un23aRz/tmRV9V/khRjFWRTP0QEVqlsYwpitqyiROU= X-Received: by 2002:a67:ce89:0:b0:47b:d7e7:a8a9 with SMTP id c9-20020a67ce89000000b0047bd7e7a8a9mr2511690vse.5.1714731488736; Fri, 03 May 2024 03:18:08 -0700 (PDT) MIME-Version: 1.0 References: <20240503020924.208431-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 3 May 2024 22:17:57 +1200 Message-ID: Subject: Re: [PATCH v2] mm/vmstat: sum up all possible CPUs instead of using vm_events_fold_cpu To: Ryan Roberts Cc: akpm@linux-foundation.org, linux-mm@kvack.org, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, david@redhat.com, v-songbaohua@oppo.com, vbabka@suse.cz, willy@infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: bw71ob19rghquxcjrbfgaunqw4bbcg7o X-Rspamd-Queue-Id: B5A048002A X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1714731489-242567 X-HE-Meta: U2FsdGVkX18e1h2BzBHD0LlHTzPIYncpKk+K5EOS2QI//m7kXsMnrNpcI4jTBXq65WKFn2CJytWhg7dHjFjln+QESQMzX4mk3qWFjequb22kb+N7BdbafcmKzJU6h8CwYRLASIAlOfh0HNev6yARlyKhPClA8yXM4rN0f1YKuhz57kVVQg9jAR8TtExZEd7ET4JjBW2jnh9LuM0/uIeAp4y0OpnPG0N2aNx6F/mI+MAoV/ZHue0pPOzWkjrm/O66MjInDW4llMIGlU5p2DH6RAp1ufZAz6u0OPYDhK+VS5W0JRLi+mM09YTvFif1gj86xjd4n9laNVK+G/0Z6PFDP6rcWx2oVuolRjmcfpcOM9ZtVKl/ADdFGz0m6q4VOwPLM6wKHz7Zxz8CP8OtXeycvTVYwldQtRxmMwrmjE8Um7X8t8hCQLbC1e5W6t87Jd3IWnmXsaKmhu04SMTaVronjwczriJDx1H1LHIbHjCvmxnnbBllNaY1/v5W2+kHGHXnnysdiLd4ygjBYJBr7J0Jjo7gBK55UuP6xyTmO02jxuOz7VZF45Zla96V21yscjD/PaO/9h0LB/Rva6YxmvoPz01ZZuluA0cnEG0rGu2/Tzvk3DMVl067nhTrzKJx0jKsvrddWB3NOBh7zl4IHM8LI/nKLgvFsx5mJ8APgK5EOYw7WL8MesJ650JTqL3hNMfZuJnjTvw2X8dGXgPVaLmyVJCuZBT1v2nm96mIIQgbApJpTTC1h8vgow+rP/5u3LWEQOze9xkGlyEkjVqgp26ApaaA34lHQ1sY1gWKRA2tX7eyHx5hsCbD+nslEiedYf7nXvqrlS73paH2vwyN1r/QnR0aEX0AGkhAlQWfj2/WxGzAsbvtzBpiuPblvr3ZE9un1nfQZRz9DPmjnaIb/ZZONCHIHWX/aFCibYNALADEGqw4tHHhpYDgjsi+upD5WVnoIF3jj6wU8UCnHNu4ZIl QosKFgJ4 T7GvJH5vSLTJoh0Zx00pL8z4og5ZeTT3UWxxoEcizcNKh6RjPBcJ+YiCtvCzOxcU9XQAEj3fTlupe9y3T+2Y/NRFL0EvU07aKnoC2JQ7zEfb+laSbHisX1R3T2Mx6NvgDmDsgnfdMY0KGvIDJDkoIHmkuz4qfnR1ujhnH0/dIbjwq45lwYbIvTdD0RqvXCfa2J5gq0AhK8CnufC7IiYLILIRJCQSK61ENqBke9PicDetgpFm4cR3ZaaXt3sZn+FZUgM5iyCAE9lMnNbw/0ykk1LPXIxH+eiJFgSoLkem+yx8kcAxytAIkTwJLDoWtCP6qThuZru4hsje8Wmv97qZ7Ok+2T7z31mU2MDNTqQ53USZ6PvzSBBDcMM+f3dCfzfjFvDSXY1qnJiLKhoRYsOvLxZPcHZzRrigMkulDKTypb/QUlW3dLbGA3bjiMjUbAVUSp6gQ9RB6h83hSDMlGX2UxApru53WaLjcbknJTZHuldUhf9yvdUVjNFNI78WtXpr8490MYmy95EKNFLgfr/QqHL2J0HqWQjuICnZyTpaiJr/nOKtP+aYp4qJwoUxFoF7P+NVDHUGsI9hQwEKEXmudkdZxe6Osw7n1K9W/ 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, May 3, 2024 at 5:16=E2=80=AFPM Ryan Roberts = wrote: > > On 03/05/2024 03:09, Barry Song wrote: > > From: Barry Song > > > > When unplugging a CPU, the current code merges its vm_events > > with an online CPU. Because, during summation, it only considers > > online CPUs, which is a crude workaround. By transitioning to > > summing up all possible CPUs, we can eliminate the need for > > vm_events_fold_cpu. > > > > Suggested-by: Ryan Roberts > > Signed-off-by: Barry Song > > --- > > originally suggested by Ryan while he reviewed mTHP counters > > patchset[1]; I am also applying this suggestion to vm_events > > > > -v2: > > also drop cpus_read_lock() as we don't care about cpu hotplug any more= ; > > -v1: > > https://lore.kernel.org/linux-mm/20240412123039.442743-1-21cnbao@gmail= .com/ > > > > [1] https://lore.kernel.org/linux-mm/ca73cbf1-8304-4790-a721-3c3a42f9d= 293@arm.com/ > > > > include/linux/vmstat.h | 5 ----- > > mm/page_alloc.c | 8 -------- > > mm/vmstat.c | 21 +-------------------- > > 3 files changed, 1 insertion(+), 33 deletions(-) > > > > diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h > > index 735eae6e272c..f7eaeb8bfa47 100644 > > --- a/include/linux/vmstat.h > > +++ b/include/linux/vmstat.h > > @@ -83,8 +83,6 @@ static inline void count_vm_events(enum vm_event_item= item, long delta) > > > > extern void all_vm_events(unsigned long *); > > > > -extern void vm_events_fold_cpu(int cpu); > > - > > #else > > > > /* Disable counters */ > > @@ -103,9 +101,6 @@ static inline void __count_vm_events(enum vm_event_= item item, long delta) > > static inline void all_vm_events(unsigned long *ret) > > { > > } > > -static inline void vm_events_fold_cpu(int cpu) > > -{ > > -} > > > > #endif /* CONFIG_VM_EVENT_COUNTERS */ > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index cd584aace6bf..8b56d785d587 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -5826,14 +5826,6 @@ static int page_alloc_cpu_dead(unsigned int cpu) > > mlock_drain_remote(cpu); > > drain_pages(cpu); > > > > - /* > > - * Spill the event counters of the dead processor > > - * into the current processors event counters. > > - * This artificially elevates the count of the current > > - * processor. > > - */ > > - vm_events_fold_cpu(cpu); > > - > > /* > > * Zero the differential counters of the dead processor > > * so that the vm statistics are consistent. > > diff --git a/mm/vmstat.c b/mm/vmstat.c > > index db79935e4a54..aaa32418652e 100644 > > --- a/mm/vmstat.c > > +++ b/mm/vmstat.c > > @@ -114,7 +114,7 @@ static void sum_vm_events(unsigned long *ret) > > > > memset(ret, 0, NR_VM_EVENT_ITEMS * sizeof(unsigned long)); > > > > - for_each_online_cpu(cpu) { > > + for_each_possible_cpu(cpu) { > > One thought comes to mind (due to my lack of understanding exactly what > "possible" means): Linux is compiled with a max number of cpus - NR_CPUS = - 512 > for arm64's defconfig. Does all possible cpus include all 512? On an 8 CP= U > system that would be increasing the number of loops by 64 times. > > Or perhaps possible just means CPUs that have ever been online? Hi Ryan, On arm64, we get possible CPUs either from device tree or ACPI. they are bo= th much less than NR_CPUS. /* * Enumerate the possible CPU set from the device tree or ACPI and build th= e * cpu logical map array containing MPIDR values related to logical * cpus. Assumes that cpu_logical_map(0) has already been initialized. */ void __init smp_init_cpus(void) for device tree case, it is, /* * Enumerate the possible CPU set from the device tree and build the * cpu logical map array containing MPIDR values related to logical * cpus. Assumes that cpu_logical_map(0) has already been initialized. */ static void __init of_parse_and_init_cpus(void) { struct device_node *dn; for_each_of_cpu_node(dn) { u64 hwid =3D of_get_cpu_hwid(dn, 0); if (hwid & ~MPIDR_HWID_BITMASK) goto next; if (is_mpidr_duplicate(cpu_count, hwid)) { pr_err("%pOF: duplicate cpu reg properties in the D= T\n", dn); goto next; } /* * The numbering scheme requires that the boot CPU * must be assigned logical id 0. Record it so that * the logical map built from DT is validated and can * be used. */ if (hwid =3D=3D cpu_logical_map(0)) { if (bootcpu_valid) { pr_err("%pOF: duplicate boot cpu reg property in DT\n", dn); goto next; } bootcpu_valid =3D true; early_map_cpu_to_node(0, of_node_to_nid(dn)); /* * cpu_logical_map has already been * initialized and the boot cpu doesn't need * the enable-method so continue without * incrementing cpu. */ continue; } if (cpu_count >=3D NR_CPUS) goto next; pr_debug("cpu logical map 0x%llx\n", hwid); set_cpu_logical_map(cpu_count, hwid); early_map_cpu_to_node(cpu_count, of_node_to_nid(dn)); next: cpu_count++; } } even for ARM32, we get that sometimes from scu_get_core_count(), eg. static void __init omap4_smp_init_cpus(void) { unsigned int i =3D 0, ncores =3D 1, cpu_id; /* Use ARM cpuid check here, as SoC detection will not work so earl= y */ cpu_id =3D read_cpuid_id() & CPU_MASK; if (cpu_id =3D=3D CPU_CORTEX_A9) { /* * Currently we can't call ioremap here because * SoC detection won't work until after init_early. */ cfg.scu_base =3D OMAP2_L4_IO_ADDRESS(scu_a9_get_base()); BUG_ON(!cfg.scu_base); ncores =3D scu_get_core_count(cfg.scu_base); } else if (cpu_id =3D=3D CPU_CORTEX_A15) { ncores =3D OMAP5_CORE_COUNT; } /* sanity check */ if (ncores > nr_cpu_ids) { pr_warn("SMP: %u cores greater than maximum (%u), clipping\= n", ncores, nr_cpu_ids); ncores =3D nr_cpu_ids; } for (i =3D 0; i < ncores; i++) set_cpu_possible(i, true); } Other architectures do exactly the same jobs. > > Either way, I guess it's not considered a performance bottleneck because,= from > memory, the scheduler and many other places are iterating over all possib= le cpus. > > > struct vm_event_state *this =3D &per_cpu(vm_event_states,= cpu); > > > > for (i =3D 0; i < NR_VM_EVENT_ITEMS; i++) > > @@ -129,29 +129,10 @@ static void sum_vm_events(unsigned long *ret) > > */ > > void all_vm_events(unsigned long *ret) > > { > > - cpus_read_lock(); > > sum_vm_events(ret); > > - cpus_read_unlock(); > > } > > EXPORT_SYMBOL_GPL(all_vm_events); > > > > -/* > > - * Fold the foreign cpu events into our own. > > - * > > - * This is adding to the events on one processor > > - * but keeps the global counts constant. > > - */ > > -void vm_events_fold_cpu(int cpu) > > -{ > > - struct vm_event_state *fold_state =3D &per_cpu(vm_event_states, c= pu); > > - int i; > > - > > - for (i =3D 0; i < NR_VM_EVENT_ITEMS; i++) { > > - count_vm_events(i, fold_state->event[i]); > > - fold_state->event[i] =3D 0; > > - } > > -} > > - > > #endif /* CONFIG_VM_EVENT_COUNTERS */ > > > > /* > Thanks Barry