Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

[Antti Kantee <pooka%cs.hut.fi@localhost>]

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 ;).