On Fri Jun 18 2010 at 04:09:30 +1000, matthew green wrote: > > Generally speaking, performance for the uniprocessor case is, in fact, > > preserved, because the actual bus-locking operations are patched away > > at startup time. > > > > However, only x86 currently supports this, I believe. Very similar code > > is required by part of DTrace (FBT) and I wish someone had both the time > > and the skills to work on it for more architectures. But that's not me. > > i ran a bunch of measurements for sparc64 when i changed GENERIC to be > MP by default (it's necessary for now, until we parse the numa-like > memory maps and avoid memory not available without depending on the CPU > it is physically attached to.) > > i couldn't observe any difference in a abunch of real world and micro- > benchmark cases, so i never even bothered with patching away code that > "isn't necessary" (though i've written code to do said patching.)
I did a microbenchmark a while ago on i386 and it showed a straggering difference of tens of %. Of course, the benchmark didn't do I/O (it tested tmpfs). But when you counted the number of locks the kernel code paths took and compared that against the cost of a bus lock, the math worked out. I don't know how expensive a bus lock is on sparc64, but at least on i386 it's very expensive (comparatively ;).