Messages in this thread | | | From | Anup Patel <> | Date | Sat, 19 Mar 2022 17:09:31 +0530 | Subject | Re: [PATCH] RISC-V: Increase range and default value of NR_CPUS |
| |
On Fri, Mar 18, 2022 at 8:44 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Fri, Mar 18, 2022 at 3:46 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > > > > On 17/03/2022 03:55, Anup Patel wrote: > > > Currently, the range and default value of NR_CPUS is too restrictive > > > for high-end RISC-V systems with large number of HARTs. The latest > > > QEMU virt machine supports upto 512 CPUs so the current NR_CPUS is > > > restrictive for QEMU as well. > > If qemu allows 512, what is the reason for limiting the kernel to 256?
There is no particular reason. I will change this to 2-512 range to match the maximum number of CPUs supported by the QEMU virt machine.
> > > > Other major architectures (such as > > > ARM64, x86_64, MIPS, etc) have a much higher range and default > > > value of NR_CPUS. > > > > What's the memory overhead for increasing this? > > It's supposed to be very small, I would expect three main sources of overhead: > > - cpumask_t variables, those grow once you go beyond the size of > an unsigned long (32 or 64 bits), so with the default just on the limit, this > makes no difference. > Note that you can run out of stack space with NR_CPUS values if > CONFIG_CPUMASK_OFFSTACK is disabled. Should not be > a problem for 512 or below.
Yes, the rationale is to have default NR_CPUS such that size of cpumask_t does not change for RV32 and RV64.
> > - percpu variables: these are dynamically allocated based on the number of > CPUs at boot time, so they should not have any real impact. > > - NR_CPUS sized arrays, these are sometimes used in place of > percpu data. This is only a problem if the array members individually > are more than a few bytes. There are not too many of these in the kernel, > as using those is discouraged.
Separately, we are also trying to replace NR_CPUS sized arrays.
Regards, Anup
| |