[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49DD068F.8040102@kernel.org>
Date: Wed, 08 Apr 2009 13:18:23 -0700
From: Tejun Heo <tj@...nel.org>
To: Ivan Kokshaysky <ink@...assic.park.msu.ru>
CC: Martin Schwidefsky <schwidefsky@...ibm.com>,
Ingo Molnar <mingo@...e.hu>, rusty@...tcorp.com.au,
tglx@...utronix.de, x86@...nel.org, linux-kernel@...r.kernel.org,
hpa@...or.com, Paul Mundt <lethal@...ux-sh.org>,
rmk@....linux.org.uk, starvik@...s.com, ralf@...ux-mips.org,
davem@...emloft.net, cooloney@...nel.org, kyle@...artin.ca,
matthew@....cx, grundler@...isc-linux.org, takata@...ux-m32r.org,
benh@...nel.crashing.org, rth@...ddle.net,
heiko.carstens@...ibm.com
Subject: Re: [GIT RFC] percpu: use dynamic percpu allocator as the default
percpu allocator
Hello,
Ivan Kokshaysky wrote:
> On Fri, Apr 03, 2009 at 09:31:10AM +0900, Tejun Heo wrote:
>> 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.
>
> Well, I've got a workaround that has zero impact on common code (patch
> appended).
>
> The idea is that we can effectively discard the "static" specifier
> by declaring a dummy variable right before actual per-cpu variable
> definition:
>
> #define DEFINE_PER_CPU_SECTION(type, name, section) \
> __attribute__((__section__(".garbage"), __unused__)) \
> char __dummy__##name; \
> __attribute__((__section__(PER_CPU_BASE_SECTION section))) \
> __weak __typeof__(type) per_cpu__##name
Nice. I think .discard would suit better for the dummy variable tho
(x86 discards the section and it seems to be more common name with
ldscript using /DISCARD/ identifier for things to throw away). Also,
it seems like if two different files happen to use static percpu
variables with the same name, they would end up sharing it, right?
That looks a tad bit dangerous.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists