Re: [PATCH] Allocate module.ref array dynamically

[Christoph Lameter <cl@linux-foundation.org>]

On Fri, 14 Nov 2008, Rusty Russell wrote:

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

But some uses do not need zeroing. They currently have no choice. And
other flags can become necessary if percpu areas gain the ability of
being dynamically extended. Zeroing percpu areas on systems with
lots of cpus can take awhile in particular since these areas may be on
remote nodes.

> > It does not allow
> > specifying an alignment therefore tight packing is not possible.
>
> It absolutely does.  That's why it takes a type!

alloc_percpu is based on __alloc_percpu which currently does not take an
alignment. Guess we could get there by removing the intermediate
functions and making alloc_percpu call cpu_alloc.

However, there are only a few places that use allocpercpu and all of
those are touched by necesssity by the full cpu alloc patchset. At mininum
we need to add the allocation flags and add cpu ops as well as review the
preemption at each call site etcin order to use the correct
call. So why bother with the old API?

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

Having macros that do type casting on results and do macro operations on
parameters look like functions does not seem to be right. We can make it
consistent at the end by renaming the remaining ones.

Having an uppercase CPU_PTR and such in the source clarifies
that something special is going on. This is consistent with other
uses in the kernel. This is CPP magic after all (see examples in
include/linux/kernel.h or slab.h f.e.)