All of lore.kernel.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: atishp@atishpatra.org
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	heinrich.schuchardt@canonical.com,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	apatel@ventanamicro.com, anup@brainfault.org
Subject: Re: [PATCH v3] RISC-V: Increase range and default value of NR_CPUS
Date: Tue, 04 Oct 2022 16:53:13 -0700 (PDT)	[thread overview]
Message-ID: <mhng-1bcc94fc-bb33-4caf-ab65-fca155189645@palmer-ri-x1c9> (raw)
In-Reply-To: <CAOnJCUKUTt1VfU+wMfxE4P21ttW5uaegXD+0oq4O4KgpGOWhaQ@mail.gmail.com>

On Thu, 18 Aug 2022 14:29:03 PDT (-0700), atishp@atishpatra.org wrote:
> On Tue, May 24, 2022 at 5:08 AM Anup Patel <anup@brainfault.org> wrote:
>>
>> Hi Palmer,
>>
>> On Wed, Apr 20, 2022 at 4:54 PM Anup Patel <apatel@ventanamicro.com> 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. Other major architectures (such as
>> > ARM64, x86_64, MIPS, etc) have a much higher range and default
>> > value of NR_CPUS.
>> >
>> > This patch increases NR_CPUS range to 2-512 and default value to
>> > XLEN (i.e. 32 for RV32 and 64 for RV64).
>> >
>> > Signed-off-by: Anup Patel <apatel@ventanamicro.com>
>>
>> Can this PATCH be considered for 5.19 ?
>>
>> Thanks,
>> Anup
>>
>> > ---
>> > Changes since v2:
>> >  - Rebased on Linux-5.18-rc3
>> >  - Use a different range when SBI v0.1 is enabled
>> > Changes since v1:
>> >  - Updated NR_CPUS range to 2-512 which reflects maximum number of
>> >    CPUs supported by QEMU virt machine.
>> > ---
>> >  arch/riscv/Kconfig | 9 ++++++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> > index 00fd9c548f26..1823f281069f 100644
>> > --- a/arch/riscv/Kconfig
>> > +++ b/arch/riscv/Kconfig
>> > @@ -275,10 +275,13 @@ config SMP
>> >           If you don't know what to do here, say N.
>> >
>> >  config NR_CPUS
>> > -       int "Maximum number of CPUs (2-32)"
>> > -       range 2 32
>> > +       int "Maximum number of CPUs (2-512)"
>> >         depends on SMP
>> > -       default "8"
>> > +       range 2 512 if !SBI_V01
>> > +       range 2 32 if SBI_V01 && 32BIT
>> > +       range 2 64 if SBI_V01 && 64BIT
>> > +       default "32" if 32BIT
>> > +       default "64" if 64BIT
>> >
>> >  config HOTPLUG_CPU
>> >         bool "Support for hot-pluggable CPUs"
>> > --
>> > 2.25.1
>> >
>
>
> Ping ?
> It would be useful to include this patch sooner than later to enable
> high HART count testing by default.

Ya, I think that's reasonable: the higher CPU counts have found a bunch 
of issues, but they're not really Linux bugs and stopping folks from 
running them is just going to stop those bugs from being fixed.  It 
seems like these higher default NR_CPUS are stable on smaller systems so 
that shouldn't hurt anything.

I'm still getting a bunch of issues when trying to run the larger CPU 
count systems in QEMU, but I think it's OK just assuming those are 
long-tail issues that would manifest anyway and are just more likely 
with the higher core counts.

So I've got this on for-next, under the rationale that the new default 
CPU counts are safe.

WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@dabbelt.com>
To: atishp@atishpatra.org
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	heinrich.schuchardt@canonical.com,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	apatel@ventanamicro.com, anup@brainfault.org
Subject: Re: [PATCH v3] RISC-V: Increase range and default value of NR_CPUS
Date: Tue, 04 Oct 2022 16:53:13 -0700 (PDT)	[thread overview]
Message-ID: <mhng-1bcc94fc-bb33-4caf-ab65-fca155189645@palmer-ri-x1c9> (raw)
In-Reply-To: <CAOnJCUKUTt1VfU+wMfxE4P21ttW5uaegXD+0oq4O4KgpGOWhaQ@mail.gmail.com>

On Thu, 18 Aug 2022 14:29:03 PDT (-0700), atishp@atishpatra.org wrote:
> On Tue, May 24, 2022 at 5:08 AM Anup Patel <anup@brainfault.org> wrote:
>>
>> Hi Palmer,
>>
>> On Wed, Apr 20, 2022 at 4:54 PM Anup Patel <apatel@ventanamicro.com> 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. Other major architectures (such as
>> > ARM64, x86_64, MIPS, etc) have a much higher range and default
>> > value of NR_CPUS.
>> >
>> > This patch increases NR_CPUS range to 2-512 and default value to
>> > XLEN (i.e. 32 for RV32 and 64 for RV64).
>> >
>> > Signed-off-by: Anup Patel <apatel@ventanamicro.com>
>>
>> Can this PATCH be considered for 5.19 ?
>>
>> Thanks,
>> Anup
>>
>> > ---
>> > Changes since v2:
>> >  - Rebased on Linux-5.18-rc3
>> >  - Use a different range when SBI v0.1 is enabled
>> > Changes since v1:
>> >  - Updated NR_CPUS range to 2-512 which reflects maximum number of
>> >    CPUs supported by QEMU virt machine.
>> > ---
>> >  arch/riscv/Kconfig | 9 ++++++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> > index 00fd9c548f26..1823f281069f 100644
>> > --- a/arch/riscv/Kconfig
>> > +++ b/arch/riscv/Kconfig
>> > @@ -275,10 +275,13 @@ config SMP
>> >           If you don't know what to do here, say N.
>> >
>> >  config NR_CPUS
>> > -       int "Maximum number of CPUs (2-32)"
>> > -       range 2 32
>> > +       int "Maximum number of CPUs (2-512)"
>> >         depends on SMP
>> > -       default "8"
>> > +       range 2 512 if !SBI_V01
>> > +       range 2 32 if SBI_V01 && 32BIT
>> > +       range 2 64 if SBI_V01 && 64BIT
>> > +       default "32" if 32BIT
>> > +       default "64" if 64BIT
>> >
>> >  config HOTPLUG_CPU
>> >         bool "Support for hot-pluggable CPUs"
>> > --
>> > 2.25.1
>> >
>
>
> Ping ?
> It would be useful to include this patch sooner than later to enable
> high HART count testing by default.

Ya, I think that's reasonable: the higher CPU counts have found a bunch 
of issues, but they're not really Linux bugs and stopping folks from 
running them is just going to stop those bugs from being fixed.  It 
seems like these higher default NR_CPUS are stable on smaller systems so 
that shouldn't hurt anything.

I'm still getting a bunch of issues when trying to run the larger CPU 
count systems in QEMU, but I think it's OK just assuming those are 
long-tail issues that would manifest anyway and are just more likely 
with the higher core counts.

So I've got this on for-next, under the rationale that the new default 
CPU counts are safe.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2022-10-04 23:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 11:24 [PATCH v3] RISC-V: Increase range and default value of NR_CPUS Anup Patel
2022-04-20 11:24 ` Anup Patel
2022-04-21  7:04 ` Heinrich Schuchardt
2022-04-21  7:04   ` Heinrich Schuchardt
2022-04-23  0:16   ` Atish Patra
2022-04-23  0:16     ` Atish Patra
2022-04-23  1:49     ` Atish Patra
2022-04-23  1:49       ` Atish Patra
2022-04-23  5:21       ` Anup Patel
2022-04-23  5:21         ` Anup Patel
2022-05-24 12:08 ` Anup Patel
2022-05-24 12:08   ` Anup Patel
2022-08-18 21:29   ` Atish Patra
2022-08-18 21:29     ` Atish Patra
2022-10-04 23:53     ` Palmer Dabbelt [this message]
2022-10-04 23:53       ` Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mhng-1bcc94fc-bb33-4caf-ab65-fca155189645@palmer-ri-x1c9 \
    --to=palmer@dabbelt.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=anup@brainfault.org \
    --cc=apatel@ventanamicro.com \
    --cc=arnd@arndb.de \
    --cc=atishp@atishpatra.org \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=paul.walmsley@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.