Re: [PATCH v4 00/40] lib/find: add atomic find_bit() primitives
Linus Torvalds <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.alsa.devel,gmane.linux.drivers.ath10k.devel,gmane.comp.emulators.kvm.devel,gmane.linux.ports.arm.kernel,gmane.linux.ports.arm.msm,gmane.linux.block,gmane.linux.bluez.kernel,gmane.linux.drivers.video-input-infrastructure,gmane.linux.ports.mips,gmane.linux.kernel.pci,gmane.linux.drivers.rdma,gmane.linux.scsi,gmane.linux.serial,gmane.linux.ports.sh.devel,gmane.linux.sound,gmane.linux.usb.general,gmane.linux.kernel.wireless.general,gmane.linux.ports.ppc64.devel,gmane.linux.network,gmane.linux.ports.sparc |
|---|---|
| Message-ID | <CAHk-=wi2R7-jyoOw27Svf1PmfDFQgBWVAH3DP5CXO+JF-BeFZA@mail.gmail.com> |
On Thu, 20 Jun 2024 at 13:20, Yury Norov <[email protected]> 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