lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <b752273b-0e94-4325-9cf8-6f16a204818b@app.fastmail.com>
Date: Thu, 11 Apr 2024 08:06:43 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Huacai Chen" <chenhuacai@...nel.org>, "Marc Zyngier" <maz@...nel.org>,
 "Tiezhu Yang" <yangtiezhu@...ngson.cn>
Cc: "Thomas Gleixner" <tglx@...utronix.de>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org, loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH v3 0/4] Give chance to build under !CONFIG_SMP for LoongArch

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ