Re: [PATCH] 2.5.21 Nonlinear CPU support

[Anton Altaparmakov]

At 06:57 12/06/02, Rusty Russell wrote:
>In message <[e-mail]> 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?

I would hope not! That would be insane. I am only talking about adding 
CPUs. Who cares if you remove one. The buffers can stay allocated. Chances 
are you will be adding a replacement very soon anyway.

>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.

And it doesn't need to.

> > 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).

I guess we disagree about the definition OS "slight" space benefit... I 
used to have a dual-Celeron with 128mb ram for a while. Throwing away 1-2mb 
just for a single driver is throwing away 1-2% of all RAM. And I would 
think adding more drivers it quickly adds up to 5-10% of RAM. And that 
sounds like way too much waste to me.

RAM is cheap if you are using a hot plug 32-CPU system, sure. But if you 
are using a low-end SMP system ram is more expensive than the rest of the 
system all together so it is not cheap at all. It is just a question of 
perspective.

>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
>optimization.

Please explain. What is cpu_possible()?

btw. I agree that CONFIG_NR_CPUS or whatever it is called would solve my 
problems. It is only in distro kernels where they are likely to leave it to 
the maximum value and most people use distro kernels...

Best regards,

         Anton