[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220829165748.1008477-1-yury.norov@gmail.com>
Date: Mon, 29 Aug 2022 09:57:44 -0700
From: Yury Norov <yury.norov@...il.com>
To: linux-kernel@...r.kernel.org
Cc: Yury Norov <yury.norov@...il.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Andrew Morton <akpm@...ux-foundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Paul E . McKenney" <paulmck@...nel.org>,
Vlastimil Babka <vbabka@...e.cz>,
Dmitry Vyukov <dvyukov@...gle.com>,
Valentin Schneider <vschneid@...hat.com>,
Sander Vanheule <sander@...nheule.net>,
Alexey Klimov <klimov.linux@...il.com>,
Eric Biggers <ebiggers@...gle.com>
Subject: [PATCH 0/4] cpumask: cleanup nr_cpu_ids vs nr_cpumask_bits mess
cpumask subsystem uses nr_cpu_ids and nr_cpumask_bits interchangeably
despite that the variables have different meaning and purpose. It makes
some cpumask functions broken.
This series cleans that mess and adds new config FORCE_NR_CPUS that
allows to optimize cpumask subsystem if the number of CPUs is known
at compile-time.
Yury Norov (4):
smp: add set_nr_cpu_ids()
lib/cpumask: delete misleading comment
lib/cpumask: deprecate nr_cpumask_bits
lib/cpumask: add FORCE_NR_CPUS config option
arch/loongarch/kernel/setup.c | 2 +-
arch/mips/kernel/setup.c | 2 +-
arch/x86/kernel/smpboot.c | 4 ++--
arch/x86/xen/smp_pv.c | 2 +-
include/linux/cpumask.h | 15 +++------------
include/linux/smp.h | 9 +++++++++
kernel/smp.c | 6 ++++--
lib/Kconfig | 10 ++++++++++
8 files changed, 31 insertions(+), 19 deletions(-)
--
2.34.1
Powered by blists - more mailing lists