Re: [GIT RFC] percpu: use dynamic percpu allocator as the defaultpercpu allocator

[Ivan Kokshaysky]

On Thu, Apr 02, 2009 at 10:57:13AM +0900, Tejun Heo wrote:
> Martin Schwidefsky wrote:
> >> Maybe we can build indirection pointer manually by twiddling with
> >> DEFINE_PER_CPU() in such a way that it doesn't have to distinguish
> >> symbols and variables?
> > 
> > Hmm, a provocative idea: can we ban the use of static per-cpu variables
> > for modules in common code? There are not many common code modules
> > doing this, with a visibility hack I found the following relevant
> > locations:
> >
> > ....
> > 
> > That would "fix" the problem as well..
> 
> Eh... I don't know.  I'd really like remove such API limitations as
> most of the necessary pieces are already there anyway, so I'd much
> prefer the re-mapping thing if it can be made to work.

On alpha, the main kernel lives in the unmapped area (superpage)
and modules get loaded into vmalloc area. Changing this means total
rewrite of the alpha code, so the remapping thing is not affordable...

On the other hand, some tricks with DEFINE_PER_CPU() are indeed possible -
for instance, using weak references we could force the compiler to
generate proper addressing mode. So DEFINE_PER_CPU(int, foo) in module
would expand to something like this:

	extern int per_cpu__foo;
	asm(".weakref per_cpu__foo, per_cpu_mod__foo");
	__attribute__((__section__(".data.percpu"))) int per_cpu_mod__foo

The main problem is that our DEFINE_PER_CPU() macro consists of more
than one definition, so it won't be possible to specify both storage class
and initializer with it.

If it's acceptable to change the semantics from

static DEFINE_PER_CPU(int, foo) = 1

to

DEFINE_PER_CPU(static, int, foo) = 1

then we're ok.

Or maybe just add STATIC_DEFINE_PER_CPU_xx() variants?

Ivan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/