Re: [PATCH] 2.5.21 Nonlinear CPU support

From: Rusty Russell (
Date: Wed Jun 12 2002 - 00:57:08 EST

In message <> you write:
> >In which case, CONFIG_NR_CPUS is the only way to get the memory
> >back...
> Why? You can get rid of all uses of NR_CPUS (except for using it as a max
> capping value so none goes above it) and always use smp_num_cpus instead.
> And make the cpu hotplug code update smp_num_cpus as appropriate.

You remove CPU 2 of 4 and the others renumber? Everyone using per-cpu
buffers needs to write code to move them. And what do apps bound to
CPU 3 do? What about *their* per-cpu data structures?

> So zero penalty for non-hotplug users and loads of penalty for hotplug
> users but frankly I couldn't care less for those. The slow path will
> trigger so seldom it is not worth thinking about the performance hit there.

And a greater requirement for everyone using per-cpu buffers (which
are becoming more common, not less) to write more code. And it
doesn't deal with CPU removal.

> There are a lot of ways to deal with this corner case dynamically, so
> please use one of them. I don't buy the "lets penalise 99% of users for the
> sake of a feature that almost noone will ever use" argument.

Sorry, you're arguing to maintain a traditionally problematic
interface for an unmeasurable time benifit, and a slight space benefit
(on SMP machines, where noone has cared space about until recently).

Now, you *could* only allocate buffers for cpus where cpu_possible(i)
is true, once the rest of the patch goes in. That would be a valid


  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:24 EST