Steven Rostedt wrote:
On Sat, 15 Apr 2006, Nick Piggin wrote:Steven Rostedt wrote:would now create a variable called per_cpu_offset__myint in the .data.percpu_offset section. This variable will point to the (if defined in the kernel) __per_cpu_offset[] array. If this was a module variable, it would point to the module per_cpu_offset[] array which is created when the modules is loaded.If I'm following you correctly, this adds another dependent load to a per-CPU data access, and from memory that isn't node-affine. If so, I think people with SMP and NUMA kernels would care more about performance and scalability than the few k of memory this saves.It's not just about saving memory, but also to make it more robust. But that's another story.
But making it slower isn't going to be popular. Why is your module using so much per-cpu memory, anyway?
Since both the offset array, and the variables are mainly read only (only written on boot up), added the fact that the added variables are in their own section. Couldn't something be done to help pre load this in a local cache, or something similar?
It it would still add to the dependent loads on the critical path, so it now prevents the compiler/programmer/oooe engine from speculatively loading the __per_cpu_offset. And it does increase cache footprint of per-cpu accesses, which are supposed to be really light and substitute for [NR_CPUS] arrays. I don't think it would have been hard for the original author to make it robust... just not both fast and robust. PERCPU_ENOUGH_ROOM seems like an ugly hack at first glance, but I'm fairly sure it was a result of design choices. -- SUSE Labs, Novell Inc.Send instant messages to your online friends http://au.messenger.yahoo.com -
: 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
![]() |