> > sure convenient. I though at the time it would be great if
> > alloc_percpu() mechanism was able to dynamically re-create all the
> > per_cpu's for new processors, that way cpu_possible_map woun't
> > probably even be needed. Or is it too much trouble for too
> little gain...
>
> The problem is to tell all subsystems to reinitialize the
> data for possible CPUs (essentially the concept of "possible"
> CPUs would need to go) It would need an reaudit of a lot of
> code. Probably quite some work.
You know Andi, I was imagining something like bitmap or linked list of
all per_cpu vars (dynamically updated) and just going through this
list... Or something like that (maybe some registration mechanism).
There are not too many of them - about two dozens, mostly all sorts of
accounting.
> I think it is better to try to figure out how many hotplug
> CPUs are supported, otherwise use a small default.
Exactly - such as on ES7000, it can support 32, 64, 128 etc. processors
depending on what configuration the customer actually ordered :)... it
should be something for that, then NR_CPUS could be either defined as
boot parameter or belong to subarchs.
Thanks,
--Natalie
> My
> current code uses disabled CPUs as a heuristic, otherwise
> half of available CPUs and it can be overwritten by the user.
>
> -Andi
>
-
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]
