Chuck Ebbert <[email protected]> wrote:
>
> In-Reply-To: <[email protected]>
>
> On Wed, 8 Feb 2006 at 20:45:02 -0800, Andrew Morton wrote:
>
> > > Its even documented in line 332 of include/linux/cpumask.h
> > >
> > > * #ifdef CONFIG_HOTPLUG_CPU
> > > * cpu_possible_map - all NR_CPUS bits set
> >
> > That seems a quite bad idea. If we know which CPUs are possible we should
> > populate cpu_possible_map correctly, whether or not CONFIG_HOTPLUG_CPU is
> > set.
>
> I don't think that's, um, "possible." Even if you could discover how many
> empty sockets there were in a system, someone might be able to hotplug
> a board with more of them on it. And there's no way to tell how many CPUs
> to reserve for each socket anyway, e.g. AMD has already announced quad-core
> processors.
Well maybe. But it's awfully presumptuous for us to say that no platform
will be capable of telling us what its maximum number of CPUs is, or even
whether certain CPUs within that range aren't possible.
<checks>
Yup, on my 2-way x86 test box, with NR_CPUS=16 we have
cpu_possible_map=0xffff.
That's just insane - the default setting for a distro kernel should be (or
will become) NR_CPUS=lots, HOTPLUG_CPU=y. All those for_each_cpu() loops
are iterating across 16 CPUs.
aargh.
> But what really surprised me is that for_each_cpu() actually walks
> cpu_possible_map and not cpu_present_map as I had assumed. This violates
> the Principle Of Least Surprise. Maybe renaming for_each_cpu to
> for_each_possible_cpu might be a good idea?
That would make sense.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
