Messages in this thread | | | Date | Thu, 14 Aug 2008 10:04:58 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug |
| |
Mathieu Desnoyers wrote: > I can't argue about the benefit of using VM CPU pinning to manage > resources because I don't use it myself, but I ran some tests out of > curiosity to find if uncontended locks were that cheap, and it turns out > they aren't. Here are the results : >
OK, let me clarify my point a bit. If you've got a kernel which is switching between UP and SMP on a regular basis, you're going to be taking the hit for the locked instructions whenever you're in the SMP state anyway. It's only going to be a workload where you're mostly UP with occasional excursions into being SMP that patching out the lock prefixes is actually going to make a difference.
And that just doesn't seem like a very likely use-case to me. Certainly I don't think it would ever happen on a physical machine. And it doesn't seem all that likely on a virtual machine either. Certainly resources are more dynamic in a virtual environment, but I think there's a fairly good chance that the domain knows from the outset whether it's going to be UP or SMP, or does the UP->SMP transition once.
(That said, the XenServer product does precisely what I say is unusual: the dom0 kernel hotplugs all the cpus so it can do ucode updates, etc, and then unplugs all but one...)
> Xeon 2.0GHz > > > Summary > > no lock prefix (s) with lock prefix (s) Speedup > make -j1 kernel/ 33.94 +/- 0.07 34.91 +/- 0.27 2.8 % > hackbench 50 2.99 +/- 0.01 3.74 +/- 0.01 25.1 % >
Yeah, that's more severe than I would have expected. Perhaps I have AMD numbers in my head.
J
| |