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

[matthew green <mrg%eterna.com.au@localhost>]

> On Thu, Jun 17, 2010 at 12:07:43PM -0400, Matthew Mondor wrote:
> > On Thu, 17 Jun 2010 10:25:59 +0000
> > Andrew Doran <ad%NetBSD.org@localhost> wrote:
> > 
> > > This is mainly down the fact that we need kernel_lock to bracket "legacy"
> > > sections of code that aren't preemption safe.  I think MULTIPROCESSOR
> > > should be sent off to the glue factory but that's another discussion :-).
> > 
> > Is there any way that performance for the uniprocessor case could be
> > preserved, where some synchronization/preemption-safe blocks are
> > unnecessary, without having conditional code when MULTIPROCESSOR?
> 
> 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.)


.mrg.