Rusty,
You've stated that you don't care about micro-optimisations,
but please consider providing an iteration construct with
O(nr_online_cpus) rather than O(NR_CPUS) (*) complexity. One
suitable data structure for this was described by this paper
<http://softlib.rice.edu/MSCP/papers/loplas.sets.ps.gz>
by Preston Briggs and Linda Torzcon.
This means keeping a logical->physical map and iterating like this:
for(i = 0; i < nr_online_cpus; ++i)
do_something_with(cpu_logical_map(i));
but since cpu add/remove events are quite rare, the overhead for
maintaining that map is negligible. Note: a cpu would be identified
by its physical number only; the logical numbers are just for
enumeration and don't need to stay the same over add/remove events.
With this and a callback that informs me of add/remove events,
I would have no problems with the nonlinear CPU patch.
(I care because my performance-monitoring counters driver by necessity
is closely tied to CPU identities and the set of online CPUs.)
/Mikael
(*) At least as long as NR_CPUS defaults to 32 on x86.
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:25 EST