Messages in this thread | | | Date | Thu, 20 Nov 2008 10:47:24 -0600 (CST) | From | Christoph Lameter <> | Subject | Re: [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.
| |