[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ADDC1C6.9090305@kernel.org>
Date: Tue, 20 Oct 2009 22:57:26 +0900
From: Tejun Heo <tj@...nel.org>
To: Ingo Molnar <mingo@...e.hu>
CC: Jeff Mahoney <jeffm@...e.com>, Jiri Kosina <jkosina@...e.cz>,
Peter Zijlstra <peterz@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>, linux-ia64@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Commit 34d76c41 causes linker errors on ia64 with NR_CPUS=4096
Ingo Molnar wrote:
> IA64 should be fixed really - we can get past the 64K of percpu data
> limit anytime we add a few more pages of per-cpu data to the kernel -
> the scheduler just happened to be the one to cross it this time.
Christoph (cc'd hi!) was talking about re-purposing one of reserved
generic registers (for current or something, I don't remember the
details) for percpu base and just getting the original one via percpu
access. With that we should be able to lift the limitation without
much performance penalty.
> Saying that all static percpu data must be below 64K, which will only be
> noticed once IA64 gets its testing act together months after it's been
> created is silly. If you want to enforce such a limit make it testable
> in a _timely_ fashion. Or fix the limit really.
Yeah, the problem probably was that it only pushes the perpcu area
very slightly over the limit depending on configuration so it's not
too surprising that it didn't get reported for some time. Also, the
linker script thing is a sanity check which is intentionally put there
to trigger when this happens so that it can be found out clearly
during build time.
In the long term, it will be a good idea to lift that restriction.
That said, I really don't think we should be adding NR_CPUS sized
array to percpu area either. Things like that quickly become very
scary with N*1024 cpu configurations.
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