Re: Vax interlock insn's (Re: Please do not yell at people for trying to help you.)

[Johnny Billquist <bqt%softjar.se@localhost>]

On 11/13/10 11:16, Anders Magnusson wrote:
> (a little side-note, but may be interesting)
>
> On 11/13/2010 04:17 AM, Matt Thomas wrote:
> > Eventually, most operations come down to compare and swap. It's just too
> > damn useful to not have as a primitive. Even if some of the platforms
> > have to emulate it somehow. Just because an architecture is 30+ years old
> > doesn't mean we are forced to ignore algorithms that came after its
> > birth.
> >
> > The VAX now has a fast non-MP emulation of atomic_cas so that should be
> > less of an issue.
> When I tested NetBSD/vax MP on an 8353 some years ago I found that
> it ended up unexpectedly slow in some situations. Some timing showed
> that the interlock insn's were _really_ slow compared to their
> non-interlocked
> version; insqti almost took 100 times of insque, bbssi were not that slow
> compared to bbss but there were an unreasonable amount of time spent
> on the buses.

Not that shocking... The cache is there for a reason. Having an 
instruction forced to go to physical memory will never be "fast".
queue instructions must be even more horrible, since they will probably 
need to lock up several memory addresses while the operation is performed.

That said, our current spin-locking, using

1:   BBSSI  $0,mutex,1b

is really not good, and not needed. The problem being that you keep 
hitting the same memory cell over and over again, over the bus, thus 
creating a lot of bus contention as well, and waiting on slow memory.

Changing it to

1:   BBSSI  $0,mutex,2f
     BRB    3f
2:   BBS    $0,mutex,2b
     BRB    1b
3:

will seriously improve performance, since the CPU will then spin hitting 
it's own CPU cache instead, and only go back to hitting memory once the 
mutex is free again.

> Using an MP VAX were just not worth it (at least not with BI bus). Better
> to optimize for UP VAX and make it work reasonable good.

I think it's definitely also worth trying to get MP code in better shape 
that it is today. I'll see if I can get my fixes to the mutexes atleast 
to work (and also locks), but rwlocks can not be fixed without more 
work. :-(

        Johnny