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-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |