Re: [9fans] interesting timing tests

[Bakul Shah <bakul+plan9@bitblocks.com>]

On Mon, 21 Jun 2010 17:21:36 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > > note the extreme system time on the 16 processor machine
> >
> > Could this be due to memory contention caused by spinlocks?
> > While locks are spinning they eat up memory bandwidth which
> > slows down everyone's memory accesses (including the one who
> > is trying to finish its work while holding the spinlock).
> > And the more processors contend, the worse it gets....
>
> perhaps.

Is there a way to check this?

Is there a way to completely shut off N processors and
measure benchmark speed slow down as function of processor?

> > How well does plan9 lock() scale with the number of processor?
>
> i think the question is, are there any spin locks that can become
> unreasonablly contended as conf.nmach goes up.  if so, i would
> think that rather than finding the optimal solution to pessimal
> use of spinlocks, we should look to optimize our use of spinlocks.

I mentioned this as something to check but I wouldn't be
surprised the problem is a combination of factors.  So first
you have to find out if this is the problem in your case
before worrying about it.

> the underlying assumption is that the contended case is rare.
> if this is not the case, then spin locks are not a good choice.

With 8 dual HT processors the probability has gone up quite a
bit!

And what will you replace spinlocks with? The underlying
issue is contention due to sharing. If you can reduce sharing
you can reduce contention. Backoff alg. seems promising
because it can reduce memory access where it matters most.
For tens & tens of processors or more, message passing is the
only way but that would be a major redesign!