On Fri, Mar 3, 2023 at 7:25 PM Yury Norov <yury.norov@xxxxxxxxx> wrote: > > Did you enable CONFIG_FORCE_NR_CPUS? If you pick it, the kernel will > bind nr_cpu_ids to NR_CPUS at compile time, and the memset() call > should disappear. I do not believe CONFIG_FORCE_NR_CPUS makes any sense, and I think I told you so at the time. This all used to just work *without* some kind of config thing, First removing the automatic "do the right thing", and then adding a config option to "force" doing the right thing seems more than a bit silly to me. I think CONFIG_FORCE_NR_CPUS should go away, and - once more - become just the "is the cpumask small enough to be just allocated directly" thing. Of course, the problem for others remain that distros will do that CONFIG_CPUMASK_OFFSTACK thing, and then things will suck regardless. I was *so* happy with our clever "you can have large cpumasks, and we'll just allocate them off the stack" long long ago, because it meant that we could have one single source tree where this was all cleanly abstracted away, and we even had nice types and type safety for it all. That meant that we could support all the fancy SGI machines with several thousand cores, and it all "JustWorked(tm)", and didn't make the normal case any worse. I didn't expect distros to then go "ooh, we want that too", and enable it all by default, and make all our clever "you only see this indirection if you need it" go away, and now the normal case is the *bad* case, unless you just build your own kernel and pick sane defaults. Oh well. Linus