Re: [PATCH] Allocate module.ref array dynamically

[Rusty Russell <rusty@rustcorp.com.au>]

On Friday 14 November 2008 01:10:32 Christoph Lameter wrote:
> On Thu, 13 Nov 2008, Rusty Russell wrote:
> > > The cpu alloc patchset gets rid of about half the hooks in the page
> > > allocator and slab allocator.
> >
> > Sure, but we could convert those today to alloc_percpu etc.
>
> The percpu_ptr macros etc are not upercase suggesting that it is a
> function but the functions do weird things like passing through the
> type. This is confusing.

No it's not, we have several like that.  And noone's going to somehow get 
confused and misuse it.  Finally, we don't change APIs just to meet some sense 
of neatness.

> alloc_percpu() does not allow specifying a GFP mask therefore does not
> support zeroing and is not extendable for the future.

It is defined to be zeroing.  And it is very unclear that (1) future 
implementations will be able to support GFP_ATOMIC reasonably, and (2) that we 
want people to do that.  If we do, we fix it.

> It does not allow
> specifying an alignment therefore tight packing is not possible.

It absolutely does.  That's why it takes a type!

> Plus the name alloc_percpu() suggests that it is a function but its a
> macro doing things with typing.

You said that before.

> CPU_PTR and THIS_CPU can be applied both to percpu pointers and
> percpu variables. The new API unifies the handling which is required in
> order for the new cpu_ops to work both on statically and dynamically
> allocated percpu data.

And if you called them per_cpu_ptr and __get_cpu_ptr they would have these 
same properties.  But now the names would be consistent.

So let's just reimplement the original API and be done.
Rusty.