Thread (11 messages) 11 messages, 2 authors, 2024-06-20

Re: [PATCH v4 00/40] lib/find: add atomic find_bit() primitives

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2024-06-20 20:32:25
Also in: alsa-devel, dmaengine, kvm, linux-arm-msm, linux-block, linux-bluetooth, linux-hyperv, linux-iommu, linux-m68k, linux-media, linux-mips, linux-pci, linux-rdma, linux-s390, linux-scsi, linux-serial, linux-sh, linux-sound, linux-usb, linux-wireless, lkml, netdev, sparclinux

On Thu, 20 Jun 2024 at 13:20, Yury Norov [off-list ref] wrote:
FORCE_NR_CPUS helped to generate a better code for me back then. I'll
check again against the current kernel.
Of _course_ it generates better code.

But when "better code" is a source of bugs, and isn't actually useful
in general, it's not better, is it.
The 5d272dd1b343 is wrong. Limiting FORCE_NR_CPUS to UP case makes no
sense because in UP case nr_cpu_ids is already a compile-time macro:
Yury, I'm very aware. That was obviously intentional. the whole point
of the commit is to just disable the the whole thing as useless and
problematic.

I could have just ripped it out entirely. I ended up doing a one-liner instead.

                Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help