lkml.org 
[lkml]   [2022]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] RISC-V: Increase range and default value of NR_CPUS
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?

> > 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.

- 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.

Arnd

\
 
 \ /
  Last update: 2022-03-18 16:15    [W:0.185 / U:2.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site