SMP and NR_CPUS are independent options, hence nr_cpu_ids may be
declared even if NR_CPUS == 1, which is useless.

Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
 kernel/smp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/smp.c b/kernel/smp.c
index 650810a6f29b..e971c9626a1b 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -1088,9 +1088,11 @@ static int __init maxcpus(char *str)
 
 early_param("maxcpus", maxcpus);
 
+#if (NR_CPUS > 1)
 /* Setup number of possible processor ids */
 unsigned int nr_cpu_ids __read_mostly = NR_CPUS;
 EXPORT_SYMBOL(nr_cpu_ids);
+#endif
 
 /* An arch may set nr_cpu_ids earlier if needed, so this would be redundant */
 void __init setup_nr_cpu_ids(void)
-- 
2.34.1

On Mon, Sep 05, 2022 at 04:08:16PM -0700, Yury Norov wrote:
> SMP and NR_CPUS are independent options, hence nr_cpu_ids may be
> declared even if NR_CPUS == 1, which is useless.

I'm thikning you're fixing the wrong problem here. Also who the heck
cares about SMP=y NR_CPUS=1 anyway?

Why do we need extra source complexity for this?

On Tue, Sep 06, 2022 at 10:53:53AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2022 at 04:08:16PM -0700, Yury Norov wrote:
> > SMP and NR_CPUS are independent options, hence nr_cpu_ids may be
> > declared even if NR_CPUS == 1, which is useless.
> 
> I'm thikning you're fixing the wrong problem here.

I'm removing dead code. If NR_CPUS == 1, nr_cpu_ids does exist, exported
as an interface variable, but never normally reached, because in some
other piece of code (not even in smp.h) it's declared conditionally. 

> Also who the heck
> cares about SMP=y NR_CPUS=1 anyway?

Build bots.

> Why do we need extra source complexity for this?

To have effective code generation for UP builds.

On Tue, Sep 06, 2022 at 07:06:31AM -0700, Yury Norov wrote:
> On Tue, Sep 06, 2022 at 10:53:53AM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 05, 2022 at 04:08:16PM -0700, Yury Norov wrote:
> > > SMP and NR_CPUS are independent options, hence nr_cpu_ids may be
> > > declared even if NR_CPUS == 1, which is useless.
> > 
> > I'm thikning you're fixing the wrong problem here.
> 
> I'm removing dead code. If NR_CPUS == 1, nr_cpu_ids does exist, exported
> as an interface variable, but never normally reached, because in some
> other piece of code (not even in smp.h) it's declared conditionally. 

Can't you simply disallow NR_CPUS==1 for SMP builds? It doesn't make
sense anyway.

> > Why do we need extra source complexity for this?
> 
> To have effective code generation for UP builds.

Again, who cares... isn't it hard to find actual UP chips these days?

It was suggested the other day we remove a whole bunch of SMP=n code and
unconditionally use SMP code, even if its pointless on UP just to make
the source simpler.

From: Peter Zijlstra
> Sent: 06 September 2022 15:37
...
> It was suggested the other day we remove a whole bunch of SMP=n code and
> unconditionally use SMP code, even if its pointless on UP just to make
> the source simpler.

All the world isn't x86.

There are some small embedded systems which are definitely UP
and where you don't want any of the SMP 'bloat'.
Architectures like NiosII will only ever be SMP.

There certainly have recently been (and probably still are)
small ppc cpu for embedded systems that are UP.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

On Tue, Sep 06, 2022 at 04:36:39PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2022 at 07:06:31AM -0700, Yury Norov wrote:
> > On Tue, Sep 06, 2022 at 10:53:53AM +0200, Peter Zijlstra wrote:
> > > On Mon, Sep 05, 2022 at 04:08:16PM -0700, Yury Norov wrote:
> > > > SMP and NR_CPUS are independent options, hence nr_cpu_ids may be
> > > > declared even if NR_CPUS == 1, which is useless.
> > > 
> > > I'm thikning you're fixing the wrong problem here.
> > 
> > I'm removing dead code. If NR_CPUS == 1, nr_cpu_ids does exist, exported
> > as an interface variable, but never normally reached, because in some
> > other piece of code (not even in smp.h) it's declared conditionally. 
> 
> Can't you simply disallow NR_CPUS==1 for SMP builds? It doesn't make
> sense anyway.

There are SMP_ON_UP and SMP_UP options in arm and mips configs. I have
no idea what do they do, but disallowing NR_CPUS==1 && SMP=y looks
unsafe...

 
> > > Why do we need extra source complexity for this?
> > 
> > To have effective code generation for UP builds.
> 
> Again, who cares... isn't it hard to find actual UP chips these days?

What about UP VMs? People are interested in UP. Check for example the
recent b81dce77cedce ("cpumask: Fix invalid uniprocessor mask assumption")

> It was suggested the other day we remove a whole bunch of SMP=n code and
> unconditionally use SMP code, even if its pointless on UP just to make
> the source simpler.

So while SMP=n is there, let's keep the code base coherent?

On Tue, Sep 06, 2022 at 04:36:39PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2022 at 07:06:31AM -0700, Yury Norov wrote:
> > On Tue, Sep 06, 2022 at 10:53:53AM +0200, Peter Zijlstra wrote:
> > > On Mon, Sep 05, 2022 at 04:08:16PM -0700, Yury Norov wrote:

...

> > > Why do we need extra source complexity for this?
> > 
> > To have effective code generation for UP builds.
> 
> Again, who cares... isn't it hard to find actual UP chips these days?

For the record, Intel produced somewhat a volume of Intel Quark chips [1],
that are UP (in 2013-2019).

[1]: https://en.wikipedia.org/wiki/Intel_Quark

-- 
With Best Regards,
Andy Shevchenko

On Tue, Sep 06, 2022 at 06:01:01PM +0300, Andy Shevchenko wrote:

> For the record, Intel produced somewhat a volume of Intel Quark chips [1],
> that are UP (in 2013-2019).

The day we drop 32bit x86 support can't be soon enough ;-)