Re: module changes

[Andrew Morton <akpm@digeo.com>]

Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> In message <15954.22427.557293.353363@gargle.gargle.HOWL> you write:
> > Rusty Russell writes:
> >  > D: This adds percpu support for modules.  A module cannot have more
> >  > D: percpu data than the base kernel does (on my kernel 5636 bytes).
> > 
> > This limitation is quite horrible.
> > 
> > Does the implementation have to be perfect? The per_cpu API can easily
> > be simulated using good old NR_CPUS arrays:
> 
> The problem is that then you have to have to know whether this is a
> per-cpu thing created in a module, or not, when you use it 8(
> 
> There are two things we can use to alleviate the problem.  The first
> would be to put a minimal cap on the per-cpu data size (eg. 8k).  The
> other possibility is to allocate on an object granularity, in which
> case the rule becomes "no single per-cpu object can be larger than
> XXX", but the cost is to write a mini allocator.
> 

Is kmalloc_percpu() not suitable?