[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AADF8FE.1060208@kernel.org>
Date: Mon, 14 Sep 2009 17:04:14 +0900
From: Tejun Heo <tj@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Arjan van de Ven <arjan@...radead.org>,
linux-kernel@...r.kernel.org, lenb@...nel.org, mingo@...e.hu,
peterz@...radead.org, yanmin_zhang@...ux.intel.com,
torvalds@...ux-foundation.org, jens.axboe@...cle.com,
David Howells <dhowells@...hat.com>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>
Subject: Re: PATCH] cpuidle: A new variant of the menu governor to boost IO
performance
Andrew Morton wrote:
> This fails to compile in linux-next:
>
> drivers/cpuidle/governors/menu-tng.o:(.discard+0x0): multiple definition of `__pcpu_unique_menu_devices'
> drivers/cpuidle/governors/menu.o:(.discard+0x0): first defined here
>
> because we have
>
> static DEFINE_PER_CPU(struct menu_device, menu_devices);
>
> in both menu.c and menu-tng.c.
>
> Despite the `static', the percpu changes in
>
> commit 7c756e6e19e71f0327760d8955f7077118ebb2b1
> Author: Tejun Heo <tj@...nel.org>
> AuthorDate: Wed Jun 24 15:13:50 2009 +0900
> Commit: Tejun Heo <tj@...nel.org>
> CommitDate: Wed Jun 24 15:13:50 2009 +0900
>
> percpu: implement optional weak percpu definitions
>
> are emitting global symbol derived from `menu_devices' and they clash.
>
> I'll rename menu_devices to fix that up, but we have a problem...
Unfortunately, this was the only way we could come up with to get
alpha and s390 working with the new percpu allocator. On other archs,
the global definition isn't necessary but config option
DEBUG_FORCE_WEAK_PER_CPU enables it so that alpha and s390 don't choke
on generic code later.
The core of the problem is that the memory model used by gcc on those
two archs assume that static symbols are reachable with small offset
but percpu variables, static or not, always end up way away. Making
all percpu variables weak and using global symbols to enforce global
uniqueness works around the problem but with the side effect you're
seeing.
If someone has any better ideas, I would happy to remove the annoying
restriction.
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