corbin@encore.UUCP (Steve Corbin) (07/26/88)
In article <566@cmx.npac.syr.edu> anand@cmx.npac.syr.edu (Rangachari Anand) writes: > > The spinlock on the multimax is implemented using the SBITIi instruction. > There seems to be only one lock manager for the Nanobus. Thus if we > have several processors waiting on spinlocks (each one for a different > lock), each processor needs exclusive access to the lock manager when > it executes SBITIi. Thus there seems to be a bottleneck. Have I got > this wrong? There is no 'lock manager' on the Nanobus. All lock operations are handled in the memory cards. The SBITIi instruction is actually executed as a set-byte-interlocked operation by the memories. Since the memory banks are 32-bits wide a lock operation requires a read-modify-write. RMW cycles on the memory cards take 8 bus clocks compared to 4 bus clocks for read or write cycles. Some sources of contention are: 1. putting multiple locks in the same 32-bit memory word. 2. putting multiple locks in the same memory bank. 3. Loading the bus and memory by having multiple processors spin on SBITIi instructions. Since RMW cycles are twice as slow as normal bus cycles it is desirable to reduce the amount of RMW's going to memory. Here is an example of how to spin out of cache instead of memory. label1: sbitib $0, LOCK_STATE(reg0) # Attempt lock bfc label3 # If fc lock granted label2: # Lock wait loop entry tbitb $0, LOCK_STATE(reg0) # Spin in cache bfc label/**/1 # Until lock is released br label/**/2 # Re-attempt lock label3: # Lock exit > Also I timed the fetch times for the DPC card. It seems to be 0.6 > microseconds for a longword from the cache while about 2.5 us from > the main memory. Does this look plausible? I'm not sure of the question. I assume you're wondering about the disparity in access times. Yes, this is reasonable and is in fact why caches are used.