Messages in this thread | | | Date | Fri, 03 Apr 2009 09:31:10 +0900 | From | Tejun Heo <> | Subject | Re: [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator |
| |
Hello,
Martin Schwidefsky wrote: > On Thu, 2 Apr 2009 11:24:18 +0400 > Ivan Kokshaysky <ink@jurassic.park.msu.ru> wrote: > >> 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? > > That is what I'm after as well. Just drop the "static" from the > DEFINE_PER_CPU statement found inside modules and it works. > > My experiments with the weak and visibility attribute failed because > the static storage class specifier together with the attribute either > causes a compile error or static just overrides the attribute.
Can STATIC_DEFINE_PER_CPU() be made to work? It's not pretty but if that's the only sensible way to reach uniform static/dynamic handling, I suppose we can ignore the slight ugliness.
Rusty, Ingo, what do you guys think?
Thanks.
-- tejun
| |