Re: [patch] CONFIG_NR_CPUS

Andrew Morton (akpm@zip.com.au)
Thu, 06 Jun 2002 12:48:57 -0700


Robert Love wrote:
>
> On Thu, 2002-06-06 at 03:15, David S. Miller wrote:
>
> > Nice. While you're at it can you fix the value on 64-bit
> > platforms when CONFIG_NR_CPUS is not specified? (it should
> > be 64, not 32)
>
> I agree, this is good. I often am toying with some debugging aid that
> is an array of NR_CPUS and waste a lot of memory with NR_CPUS stuck at
> 32... no reason my kernels should not be set to 2 or whatever I need.
>
> I have attached a patch that is Andrew's + your request, Dave. Since
> what really determines the maximum number of CPUs is the size of
> unsigned long, I used that. Cool?
>
> ...
> +#define NR_CPUS (sizeof(unsigned long) * 8)

OK. What I'll do is:

#ifdef CONFIG_SMP
#define NR_CPUS CONFIG_NR_CPUS
#else
#define NR_CPUS 1
#endif

and then go edit every SMP-capable arch's config.in/Config.help
files. But the arch maintainers should test one case please - x86
was locking up at boot on quad CPU with NR_CPUS=2. Others may do
the same.

About a quarter of the bloat is runqueues. If we could dynamically
allocate those in sched_init() it would be good, because presumably
vendor kernels will be configured for the maximum number of CPUs.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/