lkml.org 
[lkml]   [2008]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Allocate module.ref array dynamically
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.



\
 
 \ /
  Last update: 2008-11-20 17:51    [W:0.068 / U:1.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site