Heiko Carstens a écrit :
> Actually, x86 appears to be the only arch which suffers this braindamage.
> The rest use CPU_MASK_NONE (or just forget to initialise it and hope that
> CPU_MASK_NONE equals all-zeroes).
s390 will join, as soon as the cpu_possible_map fix is merged...
What cpu_possible_map fix?
This one:
http://lkml.org/lkml/2006/2/8/162
Oh, OK. Ow, I don't think you want to do that. It means that all those
for_each_cpu() loops will now be iterating over all NR_CPUS cpus, whether
or not they're even possible.
That's ok. We're mainly running under z/VM where you can attach new virtual
cpus on the fly to the virtual machine (up to 64 cpus).
The only difference to before is that it was possible to limit the waste of
resources by passing a number with 'maxcpus'. This value was used to generate
the cpu_possible_map.
But since the map needs to be ready when we return from setup_arch, we don't
have access to max_cpus, unless we parse commandline on our own...
Then it's OK to clear bits from cpu_possible_map once you have max_cpus value
for (cpu = max_cpus ; cpu < NR_CPUS ; cpu++)
cpu_clear(cpu, cpu_possible_map);
-
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]
