Re: [PATCH] Allocate module.ref array dynamically

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

On Sun, 16 Nov 2008, Rusty Russell wrote:

> > And other flags can become necessary if percpu areas gain the ability of
> > being dynamically extended.
>
> And other flags become impossible, eg. GFP_ATOMIC.

There are other flags that may become relevant like GFP_THISNODE, reclaim
settings (counter allocation from filesystem context) etc.

> The strange indirection was from someone's failed experiment at only
> allocating only online cpus.  We should kill that as a separate patch.

I fully agree.

> There are several seperate things here (this is to make sure my head is
> straight and to clarify for others skimming):
>
> 1) Make the dynamic percpu allocator use the static percpu system.
>    - Agreed, always the aim, never quite happened.

Ack.

> 2) Make zeroing optional
>    - Disagree, adds API complexity for corner case with no gain.  Using
>      gfp_t for it is even worse, since it implies GFP_ATOMIC is valid or
>      sensible.

It does not imply that. Various allocations limit the type of flags that
can be passed. Also there may be situations in which GFP_ATOMIC will make
sense in the future f.e. if a percpu counter structure has to be allocated
from an interrupt context.

GFP_FS, GFP_IO, GFP_NOFAIL GFP_ZERO GFP_NOMEMALLOC GFP_THISNODE and
GFP_HARDWALL could all be relevant for a dynamically extending percpu
allocator since memory reclaim could be triggered.

> 3) Change API to use CAPS for macros
>    - Strongly disagree, Linus doesn't use CAPS for type-taking macros
>      (list_entry, container_of, min_t), it's ugly, and status-quo wins.

That is the cause for many problems because people assume these can be
handled like a function.

> 4) Get rid of unused "online-only" percpu allocators.
>    - Agree, and will simplify implementation and macro tangle.

Ack.

> 5) Make dynamic percpu var access more efficient.
>    - Agree, obviously.  x86 for the moment, the rest can follow (or not).

Ack.
>
> 6) Use percpu allocations more widely.
>    - Definitely, I have some other patches which use it too.  And makes even
>      more sense once (5) is done.

Ack.

> 7) Make percpu area grow dynamically.
>    - Yes, but a thorny tangle esp. with IA64.  The cmdline hack is probably
>      sufficient meanwhile, and parallels can be drawn with vmalloc.

Allright. Please check with David Miller who wants to allocate thousands
of network interfaces which all need a MIB block.