Messages in this thread | | | Date | Tue, 20 Oct 2009 22:58:20 +0900 | From | Tejun Heo <> | Subject | Re: Commit 34d76c41 causes linker errors on ia64 with NR_CPUS=4096 |
| |
Of course I forgot to actually cc. Cc'ing and quoting whole body. Sorry.
Tejun Heo wrote: > 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.
-- tejun
| |