Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

I presume you know that the 3880 controller did not do what today we
call command queuing, so I think you were referring to a potential
queue in the host.  That being the case, the controller doesn't know
if there is a queue or not.  So given that, why not start reading
record 1 on the next track.  If a request comes in, you can abandon
the read to service the request - no harm, no foul.  If there isn't,
and you subsequently get a request for that track, it's a big win.
The only potential loss is if you get a request for the track that was
LRU and got pushed out of the cache.

over optimizing full track read ahead could lock out other tasks that
had competing requirements for other parts of the disk.

trivia: early 70s, IBM decided to add virtual memory to all 370s. Early
last decade I was asked to tract down the decsion. I found staff member
to executive making the decision. Basically MVT (IBM's high end, major
batch system) storage management was so bad that (multiprogramming)
region sizes had to be specified four times larger than used, as a
result typical (high-end) 1mbyte 370/165 only ran four regions
concurrently, insufficient to keep system busy and justified.  Running
MVT in a 16mbyte virtual address space (sort of like running MVT in CP67
16mbyte virtual machine) would allow concurrent regions to be increased
by factor of four times (caped at 15 because of 4bit storage protect
key) with little or no paging. Later as high-end systems got larger,
they needed more than 15 concurrent running regions ... and so switched
from VS2/SVS (single 16mbyte virtual address space) to VS2/MVS (a
separate 16mbyte virtual address space for each "region", went through
MVT->VS2/SVS->VS2/MVS)

along the way, I had been pontificating that DASD (disks) relative
system throughput has been decreasing ... in 1st part of 80s, I turned
out analysis that in the 15yr period since the IBM 360 1st ships,
DASD/disk relative system throughput had declined by an order of
magnitude (i.e. DASD got 4-5 times faster while systems got 40-50 times
faster). Some DASD division executive took exception and assigned the
division performance group to refute the claim ... after a few weeks,
they came back and bascially said I had slightly understated the
issue. The performance group then respun the analysis for user group
presenation on how to configure disks and filesystem to improve system
throughput (SHARE63, B874, 16Aug1984).

1970 IBM 2305 fixed-head disk controller supported 8 separate psuedo
device addresses ("multiple exposure") for each 2305 disk ... each
having channel program that the controller could optimize. In 1975, I
was asked to help enhance low-end 370 that had integrated channels and
integrated device controllers ... and I wanted to upgrade microcode so I
just update a queue of channel programs that the (integrated microcode)
controller could optimize (wasn't allowed to ship the product).

Later I wanted to add "multiple exposure" support to 3830 (precursor to
the 3880) for 3350 (moveable arm) disks (IBM east coast group was
working on emulated electronic memory disks, considered it might compete
and got it vetoed. sometime later they got shutdown, they were told IBM
was selling all electronic memory it could make as higher markup
processor memory).

--
virtualization experience starting Jan1968, online at home since Mar1970