linux/arch
Linus Torvalds 596ff4a09b cpumask: re-introduce constant-sized cpumask optimizations
Commit aa47a7c215 ("lib/cpumask: deprecate nr_cpumask_bits") resulted
in the cpumask operations potentially becoming hugely less efficient,
because suddenly the cpumask was always considered to be variable-sized.

The optimization was then later added back in a limited form by commit
6f9c07be9d ("lib/cpumask: add FORCE_NR_CPUS config option"), but that
FORCE_NR_CPUS option is not useful in a generic kernel and more of a
special case for embedded situations with fixed hardware.

Instead, just re-introduce the optimization, with some changes.

Instead of depending on CPUMASK_OFFSTACK being false, and then always
using the full constant cpumask width, this introduces three different
cpumask "sizes":

 - the exact size (nr_cpumask_bits) remains identical to nr_cpu_ids.

   This is used for situations where we should use the exact size.

 - the "small" size (small_cpumask_bits) is the NR_CPUS constant if it
   fits in a single word and the bitmap operations thus end up able
   to trigger the "small_const_nbits()" optimizations.

   This is used for the operations that have optimized single-word
   cases that get inlined, notably the bit find and scanning functions.

 - the "large" size (large_cpumask_bits) is the NR_CPUS constant if it
   is an sufficiently small constant that makes simple "copy" and
   "clear" operations more efficient.

   This is arbitrarily set at four words or less.

As a an example of this situation, without this fixed size optimization,
cpumask_clear() will generate code like

        movl    nr_cpu_ids(%rip), %edx
        addq    $63, %rdx
        shrq    $3, %rdx
        andl    $-8, %edx
        callq   memset@PLT

on x86-64, because it would calculate the "exact" number of longwords
that need to be cleared.

In contrast, with this patch, using a MAX_CPU of 64 (which is quite a
reasonable value to use), the above becomes a single

	movq $0,cpumask

instruction instead, because instead of caring to figure out exactly how
many CPU's the system has, it just knows that the cpumask will be a
single word and can just clear it all.

Note that this does end up tightening the rules a bit from the original
version in another way: operations that set bits in the cpumask are now
limited to the actual nr_cpu_ids limit, whereas we used to do the
nr_cpumask_bits thing almost everywhere in the cpumask code.

But if you just clear bits, or scan for bits, we can use the simpler
compile-time constants.

In the process, remove 'cpumask_complement()' and 'for_each_cpu_not()'
which were not useful, and which fundamentally have to be limited to
'nr_cpu_ids'.  Better remove them now than have somebody introduce use
of them later.

Of course, on x86-64 with MAXSMP there is no sane small compile-time
constant for the cpumask sizes, and we end up using the actual CPU bits,
and will generate the above kind of horrors regardless.  Please don't
use MAXSMP unless you really expect to have machines with thousands of
cores.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-03-05 14:30:34 -08:00
..
alpha VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
arc - Daniel Verkamp has contributed a memfd series ("mm/memfd: add 2023-02-23 17:09:35 -08:00
arm ARM: SoC fixes for 6.3, part 1 2023-02-27 10:09:40 -08:00
arm64 arm64 fixes: 2023-03-02 14:57:53 -08:00
csky rch/csky patches for 6.3 2023-02-27 09:27:31 -08:00
hexagon VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
ia64 cpumask: re-introduce constant-sized cpumask optimizations 2023-03-05 14:30:34 -08:00
loongarch LoongArch changes for v6.3 2023-03-01 09:27:00 -08:00
m68k VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
microblaze VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
mips a few more cleanups/fixes 2023-03-02 10:34:14 -08:00
nios2 VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
openrisc VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
parisc VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
powerpc powerpc fixes for 6.3 #2 2023-03-04 11:20:42 -08:00
riscv VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
s390 s390 updates for 6.3 merge window part 2 2023-03-03 09:38:01 -08:00
sh Kbuild updates for v6.3 2023-02-26 11:53:25 -08:00
sparc VM_FAULT_RETRY fixes 2023-03-05 11:07:58 -08:00
um This pull request contains the following changes for UML: 2023-03-01 09:13:00 -08:00
x86 A small set of updates for x86: 2023-03-05 11:27:48 -08:00
xtensa - Daniel Verkamp has contributed a memfd series ("mm/memfd: add 2023-02-23 17:09:35 -08:00
.gitignore
Kconfig arch/Kconfig: fix indentation 2023-02-09 17:03:20 -08:00