Received-SPF: pass (google.com: domain of linux-kernel+bounces-139813-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-379-gabd37849b7-fm-20240408.001-gabd37849
Precedence: bulk
MIME-Version: 1.0
Message-Id: <b752273b-0e94-4325-9cf8-6f16a204818b@app.fastmail.com>
In-Reply-To: 
 <CAAhV-H6bHudfUVE4SWY88mxmLhFok9DS8UyODSZEdUJ816V8Rg@mail.gmail.com>
References: <20240411010510.22135-1-yangtiezhu@loongson.cn>
 <CAAhV-H6bHudfUVE4SWY88mxmLhFok9DS8UyODSZEdUJ816V8Rg@mail.gmail.com>
Date: Thu, 11 Apr 2024 08:06:43 +0200
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Huacai Chen" <chenhuacai@kernel.org>, "Marc Zyngier" <maz@kernel.org>,
 "Tiezhu Yang" <yangtiezhu@loongson.cn>
Cc: "Thomas Gleixner" <tglx@linutronix.de>, loongarch@lists.linux.dev,
 linux-kernel@vger.kernel.org, loongson-kernel@lists.loongnix.cn
Subject: Re: [PATCH v3 0/4] Give chance to build under !CONFIG_SMP for LoongArch
Content-Type: text/plain

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