IBM 610 workstation computer 3413

ref:

so the os-360 smp kernels had a single "spin-lock" around the whole kernel ... i.e. the first thing on entering a kernel interrupt handler ... do the TS-BNZ spin-lock loop and then at exit from the kernel (into application code), do the clear of the lock.

this could take a kernel developed for single-processor use and quickly and trivially adapt it for multi-processor use. the problem was that if the overall system spent any appreciable time executing in the kernel ... a large percentage of multi-processor operation would be spent in the TS-BNZ spin-loop.

charlie's work on fine-grain locking was to have lots of different locks and only little snippets of code between obtaining a specific lock and clearing the lock. in the single-kernel-lock scenario, there could be lots of "lock" contention ... processors spending huge amounts of time trying to obtain the single, kernel lock. having lots of unique locks around different little snippets of code, could hopefully reduce the amount of lock contention (and time processors spent spinning on locks).

there are also two different paradigms ... "locking" code and "locking" data structures. when "locking" code there is unique block for a specific sequence of code. when "locking" data structures, there is unique locks for specific data structures ... whenever some code (regardless of its location) attempts to operate on a specific data structure, it needs to obtain the buttociated data structure lock. the use of a "code" lock will only appear in a single piece of code. the use of a "data structure" lock can appear in large number of different code locations ... whenever there is activity involved a specific data structure. fine-grain locking tended to be data-structure specific ... rather than code specific.

so for vamps, I attempted to do a hack ... that gained the majority of the benefits of fine-grain locking with the minimum work involved in single kernel spin-lock. something like the highest executed kernel code ... typically around interrupt handlers were modified with locks for fine-grain locking paradigm. this drew on some of the ecps analysis ... looking for the highest used kernel pathlengths for migration into microcode. misc. past ecps postings:

then there was a single lock for the rest of the kernel, however instead of spinning, it would queue a light-weight kernel work request and go off to the dispatcher to look for other application code to execute. vamps was going to have up to five processors in a multiprocessor configuration. as long as the single-processor scenario spent in the single-lock, low-useage kernel code was well under 20percent (of a single processor) ... then there would little time wasted in lock-contention in a five-way operations. i referred to the vamps kernel lock as a bounce-lock ... rather than a spin-lock (processor would bounce off the kernel lock if it couldn't obtain it and go off to look for other work ... rather than spinning). misc. vamps postings

the objective was to make the absolute minimum amount of code changes to a single processor kernel for the maximum possible thruput in a 5-way, smp configuration.

in the original vamps design ... all of the high-use stuff was actually dropped into the microcode of the individual processors (dispatching, interrupt handling and some number of other things, again some adapted from ecps). when end required some use of the low-useage kernel function (still in 370 code), the microcode would attempt to obtain the kernel lock and then exit into the 370 code. if the microcode couldn't obtain the kernel lock, it would queue a work requests for the 370 kernel code and go off to the (microcode) dispatcher, looking for other work to do.

from a 370 kernel code standpoint ... the semantics look more like the smp "machine" dispatcher found later in the i432.

when vamps was end, the design was adapted from a highly modified microcode design to a much more normal 370 kernel ... with a combination of fine-grain locks involving little pieces of high-use kernel ... typically around the interrupt handlers ... and the majority of the (low-use) kernel handled by a single kernel "bounce" lock.

later, the develpment group begain to refer to it as a "defer" lock ... representing the semantics buttociated with the unit of work ... as opposed to the semantics buttociated with a specific processor end (as i had originally referred to the lock).

--