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

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

On Thu Jun 17 2010 at 12:21:41 -0400, Thor Lancelot Simon wrote:
> 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.

On a slight tangent, since I can't remember if I've mentioned this on
a list before:

If your workload partitions somewhat easily, you can get uniprocessor
locking performance on a multiprocessor host by running several rump
kernels with one virtual CPU each.  Since exclusion is done already at
the level of the CPU scheduler, all bus locking is optimized out for
normal locks.  E.g. if you have 16 host CPUs, you can have 16 worker
kernels all with uniprocessor locking.  Plus, you can have your 16 CPUs
executing networking code in parallel on NetBSD ...