🚀 go-pugleaf

Frank McConnell <f...@reanimators.org> writes:

> DISP, and its disable/enable pair PSDB and PSEB.  All privileged
> instructions, not intended for user code, although I have read and
> written privileged non-system code use PSDB/PSEB to stall the
> dispatcher.  DISP effectively causes an interrupt (either when the
> DISP instruction is executed, or when a later PSEB returns the
> pseudo-disable count to 0), and that gets the actual MPE dispatcher
> code involved.

VAMPS was a multiprocessor version of 370/125. The 370/115 & 370/125
had somewhat unique internal architectures (for 370). They consisted
of a 9port (370) memory bus and several microprocessor engines
installed on the memory bus ports.

In the 370/115, all the microprocessors were identical ... they just had
different programs loaded that were function specific ... i.e. emulate
370 processor, disk controller, unit record controller, tape
controller, telecommunication controller, etc.

The 370/125 differed from the 115 in that the engine used for the 370
emulation was about 50% faster than the other engines.

VAMPS was a 370/125 project to install up to five "370 engines" in the
same configuration (in max. 370 configuration, it only left four ports
for controller engines).

For the VAMPS project, migrated the VM/370 dispatcher, much of the
first level interrupt handlers, and much of the page I/O supervisor
into "mirocode" of the various engines; and of course there were the
corresponding (privilege) instructions to interface to these migrated
functions ... i.e. add task to dispatching queue, add page request to
page I/O queue, etc.

The 370 "engines" also had an enhanced version of VM microcode assist
(in part because I was also concurrently working on ECPS for
virgil/tully).

The 370 "microcode" engine would attempt to perform all functions ...
including various microcode assist operations. If it found that it
could not complete an operation and needed survices of the (software)
kernel, it would check to see if any processor was already operating
in kernel mode, if so it would just queue a light-weight request with
sufficient information to invoke the necessary processing and go
looking for some other work. If there was no processor already in
kernel mode, it would just enter kernel mode.

The point was that 1) the then existing VM/370 kernel didn't have full
symmetric multiprocessing support 2) the changes for the above
amounted to relatively trivial number of lines of code in the kernel
software, 3) the measured percent kernel time (based on the enhanced
microcode assist) was much less than 20% (so a five engine
configuration might have something like total max of 80% a single
engine in kernel mode).

When the VAMPS project was terminated, in part because the processing
power overlapped the virgil/tully configurations ... we adopted the
microcode design to kernel software. 

High-activity paths of the kernel that received control directly from
the first level interrupt handlers were modified to support fine-grain
locking symmetrical multiprocessing. However, the majority of the
kernel (in terms of total code size, but not in terms of percent
pathlength) was behind a single "kernel" lock.

The traditional IBM mainframe approach to symmetric multiprocessing up
until that time was single "kernel" lock where a processor would
"spin" on the kernel lock until it was available.

Adopting the VAMPS microcode dispatcher design to the software kernel,
resulted instead something that I called a "bounce" lock; aka if the
processor didn't obtain the "kernel" lock, it would queue a
light-weight request for kernel lock/services and go off to the
dispatcher to find some other work to do.

This implementation provided the absolute maximum symmetric
multiprocessor thruput per line of SMP code modifications.

random refs:
http://www.garlic.com/~lynn/subtopic.html#smp Multiprocessor, tightly-coupled, SMP, compare&swap
http://www.garlic.com/~lynn/subtopic.html#fairshare Performance and/or Scheduling

http://www.garlic.com/~lynn/95.html#5 Who started RISC? (was: 64 bit Linux?)
http://www.garlic.com/~lynn/95.html#6 801
http://www.garlic.com/~lynn/99.html#149 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/2000.html#11 I'm overwhelmed
http://www.garlic.com/~lynn/2000.html#12 I'm overwhelmed
http://www.garlic.com/~lynn/2000c.html#30 internal corporate network, misc.
http://www.garlic.com/~lynn/2000c.html#49 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000e.html#7 Ridiculous
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#7 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#8 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#40 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
http://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2001h.html#69 Very CISC Instuctions (Was: why the machine word size ...)

-- 
Anne & Lynn Wheeler   | ly...@garlic.com -  http://www.garlic.com/~lynn/