The changes of irqchip have been merged into the irq/core branch of tip.
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=42a7d887664b
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=a64003da0ef8
This version is only related with arch/loongarch and based on 6.9-rc3,
the first 3 patches with detailed commit message are preparations for
patch #4.
Tested with the following configs:
(1) CONFIG_NUMA=n, CONFIG_SMP=n
(2) CONFIG_NUMA=n, CONFIG_SMP=y
(3) CONFIG_NUMA=y, CONFIG_SMP=n (not allowed due to NUMA select SMP)
(4) CONFIG_NUMA=y, CONFIG_SMP=y
Tiezhu Yang (4):
LoongArch: Move CONFIG_HAVE_SETUP_PER_CPU_AREA related code to smp.c
LoongArch: Refactor get_acpi_id_for_cpu() related code
LoongArch: Save and restore PERCPU_BASE_KS for ACPI S3 state
LoongArch: Give chance to build under !CONFIG_SMP
arch/loongarch/Kconfig | 4 +-
arch/loongarch/include/asm/acpi.h | 8 +++-
arch/loongarch/include/asm/smp.h | 5 +++
arch/loongarch/kernel/acpi.c | 9 +++-
arch/loongarch/kernel/irq.c | 2 +
arch/loongarch/kernel/machine_kexec.c | 2 +-
arch/loongarch/kernel/numa.c | 58 --------------------------
arch/loongarch/kernel/smp.c | 59 +++++++++++++++++++++++++++
arch/loongarch/power/suspend.c | 4 +-
9 files changed, 87 insertions(+), 64 deletions(-)
--
2.42.0
Hi, Marc and Arnd,
I remember that you both suggested not introducing NOSMP support for a
modern architecture which brings additional complexity. I wonder if
you still have the same attitude now. I will merge this series only if
you think it is worthy to introduce NOSMP now.
Huacai
On Thu, Apr 11, 2024 at 9:05 AM Tiezhu Yang <[email protected]> wrote:
>
> The changes of irqchip have been merged into the irq/core branch of tip.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=42a7d887664b
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=a64003da0ef8
>
> This version is only related with arch/loongarch and based on 6.9-rc3,
> the first 3 patches with detailed commit message are preparations for
> patch #4.
>
> Tested with the following configs:
> (1) CONFIG_NUMA=n, CONFIG_SMP=n
> (2) CONFIG_NUMA=n, CONFIG_SMP=y
> (3) CONFIG_NUMA=y, CONFIG_SMP=n (not allowed due to NUMA select SMP)
> (4) CONFIG_NUMA=y, CONFIG_SMP=y
>
> Tiezhu Yang (4):
> LoongArch: Move CONFIG_HAVE_SETUP_PER_CPU_AREA related code to smp.c
> LoongArch: Refactor get_acpi_id_for_cpu() related code
> LoongArch: Save and restore PERCPU_BASE_KS for ACPI S3 state
> LoongArch: Give chance to build under !CONFIG_SMP
>
> arch/loongarch/Kconfig | 4 +-
> arch/loongarch/include/asm/acpi.h | 8 +++-
> arch/loongarch/include/asm/smp.h | 5 +++
> arch/loongarch/kernel/acpi.c | 9 +++-
> arch/loongarch/kernel/irq.c | 2 +
> arch/loongarch/kernel/machine_kexec.c | 2 +-
> arch/loongarch/kernel/numa.c | 58 --------------------------
> arch/loongarch/kernel/smp.c | 59 +++++++++++++++++++++++++++
> arch/loongarch/power/suspend.c | 4 +-
> 9 files changed, 87 insertions(+), 64 deletions(-)
>
> --
> 2.42.0
>
On Thu, Apr 11, 2024, at 06:26, Huacai Chen wrote:
>
> I remember that you both suggested not introducing NOSMP support for a
> modern architecture which brings additional complexity. I wonder if
> you still have the same attitude now. I will merge this series only if
> you think it is worthy to introduce NOSMP now.
It's an interesting question, as we have recently discussed two
opposite ideas and may end up doing both (or possible neither)
in the future:
- On x86, there is no real reason to need non-SMP kernels as the
memory savings are fairly small, and it tends to break because
of lack of users testing it.
- On arm64, we have never supported non-SMP kernels, but I have
looked at possibly adding this because there are still popular
ARM based system-in-package products with less than 128MB of
built-in RAM and only a single CPU. As these are moving from
32-bit to 64-bit cores, it becomes more interesting to build
a 64-bit UP kernel and save multiple megabytes.
I think loongarch64 is in the same place as arm64 and riscv64
(which does allow non-SMP builds) here, and there are good
reasons to allow it on all of them now, even if we previously
never had a need for it.
That said, both the 9% observed performance improvements that
Tiezhu Yang reported, and the memory savings that I saw are
probably higher than they should be, so we may also want to
investigate that further to see if we can improve the SMP
kernel to better support UP runs.
Arnd
Hi, Arnd,
On Thu, Apr 11, 2024 at 2:07 PM Arnd Bergmann <[email protected]> wrote:
>
> On Thu, Apr 11, 2024, at 06:26, Huacai Chen wrote:
> >
> > I remember that you both suggested not introducing NOSMP support for a
> > modern architecture which brings additional complexity. I wonder if
> > you still have the same attitude now. I will merge this series only if
> > you think it is worthy to introduce NOSMP now.
>
> It's an interesting question, as we have recently discussed two
> opposite ideas and may end up doing both (or possible neither)
> in the future:
>
> - On x86, there is no real reason to need non-SMP kernels as the
> memory savings are fairly small, and it tends to break because
> of lack of users testing it.
>
> - On arm64, we have never supported non-SMP kernels, but I have
> looked at possibly adding this because there are still popular
> ARM based system-in-package products with less than 128MB of
> built-in RAM and only a single CPU. As these are moving from
> 32-bit to 64-bit cores, it becomes more interesting to build
> a 64-bit UP kernel and save multiple megabytes.
>
> I think loongarch64 is in the same place as arm64 and riscv64
> (which does allow non-SMP builds) here, and there are good
> reasons to allow it on all of them now, even if we previously
> never had a need for it.
OK, thanks. This means you agree to support non-SMP on LoongArch now,
then I will review this series carefully.
Huacai
>
> That said, both the 9% observed performance improvements that
> Tiezhu Yang reported, and the memory savings that I saw are
> probably higher than they should be, so we may also want to
> investigate that further to see if we can improve the SMP
> kernel to better support UP runs.
>
> Arnd
>
On Thu, 2024-04-11 at 08:06 +0200, Arnd Bergmann wrote:
> On Thu, Apr 11, 2024, at 06:26, Huacai Chen wrote:
> >
> > I remember that you both suggested not introducing NOSMP support for a
> > modern architecture which brings additional complexity. I wonder if
> > you still have the same attitude now. I will merge this series only if
> > you think it is worthy to introduce NOSMP now.
>
> It's an interesting question, as we have recently discussed two
> opposite ideas and may end up doing both (or possible neither)
> in the future:
>
> - On x86, there is no real reason to need non-SMP kernels as the
> memory savings are fairly small, and it tends to break because
> of lack of users testing it.
FWIW I'm still running the latest Linux kernel on a Athlon 64 3000+
launched in 2004 with !CONFIG_SMP :).
No objection to this paragraph (and other paragraphs) though.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University