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 -- 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
|