tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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


Home | Main Index | Thread Index | Old Index