> I agree that one cache line bouncer is devastating to performance. But > as Mathieu said, it is better than a global tracer with lots of bouncing > going on. Scale up enough, and it becomes more than just a performance problem. When SGI first tried to boot on 512 cpus they found the kernel hung completely because of a single global atomic counter for how many interrupts there were. With HZ=1024 and 512 cpus the ensuing cache line bouncing storm from each interrupt took longer to resolve than the interval between interrupts. With higher event rates (1KHz seems relatively low) this wall will be a problem for smaller systems too. > ftrace does not have a global counter, but on some boxes with out of > sync TSCs, it could not find race conditions. I had to pull in logdev, > which found the race right away, because of this atomic counter. Perhaps this needs to be optional (and run-time switchable). Some users (tracking performance issues) will want the tracer to have the minumum possible effect on the system. Others (chasing race conditions) will want the best possible ordering of events between cpus[*]. -Tony [*] I'd still be concerned that a heavyweight strict ordering might perturb the system enough to make the race disappear when tracing is enabled. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html