REAL memory column in SDSF 4603

some of this cropped up during the early days of os-vs2 svs development.

at the time, cp67 was one of the few relatively succesful operating systems that supported virtual memory, paging, etc (at least in the ibm camp). as a result some of the people working on os-vs2 svs was looking at pieces of cp67 for example.

one of the big issues facing transition from real memory mvt to virtual memory environment was what to do about channel programs.

in virtual machine environment, the guest operating system invokes channel programs ... that have virtual addresses. channel operation runs asyncronously with real addresses. as a result, cp67 had a lot of code (module CCWTRANs) to create an exact replica of the virtual channel program ... but with real addresses (along with fixing the buttociated virtual pages at real addresses for the duration of i-o operation). these were "shadow" channel programs.

svs had a compareable problem with channel programs generated in the application space and pbutting the address to the kernel with EXCP-SVC0. the svs kernel now was faced with also scanning the virtual channel program and created a replica-shadow version using real addreses. the initial work involved taking CCWTRANS from cp67 and crafting it into the said of the SVS development effort.

one of the other issues was that the POK performance modeling group got involved in doing low-level event modeling of os-vs2 paging operations. one of their conclusions ... which I argued with them about ... was that replacing non-changed pages was more efficient than selecting a change page for replacement. no matter how much arguing they were adament that on a page fault ... for a missing page ... the page replacement algorithm should look for a non-changed page to be replaced (rather than a changed page). This reasoning was that replacing a non-changed page took significantly less effort (there was no writing out required for the current page).

the issue is that in LRU (least recently used) page replacement strategy ... you are looking to replace pages that have the least likelyhood of being used in the near future. the non-changed-changed strategy resulted in less weight being placed on whether the page would be needed in the near future. this strategy went into svs and continued into the very late 70s (with mvs) before it was corrected.

finally it dawned on somebody that the non-changed-changed strategy resulted in replacing relatively high-use, comonly used linkpack executable (non-changed) pages before more lightly referenced, private application data (changed) pages.

these days there is a lot of trade-off trying to move data between memory in really large block transfers .... and using excess electronic memory to compensate for disk i-o bottlenecks. in the vs1 handshaking scenario ... vs1 letting vm do its paging in 4k blocks was frequently signifantly more efficient than paging in 2k blocks (made less efficient use of real storage, but it was a reasonable trade-off since there was effectively mode real storage resources than there were disk i-o access resources).

later "big pages" went to 40k (10 4k page) 3380 track demand page transfers. vm-hpo3.4 would typically do more total 4k transfers than vm-hpo3.2 (for the same workload and thruput) ... however, it could do the transfers with much fewer disk accesses; it made less efficient use of real storage, but more efficient use of disk i-o accesses (again trading off real storage resource efficiency for disk i-o resource efficiency).

... or somewhat reminiscent of a line that I started using as an undergraduate in conunction with dynamic adaptive scheduling; "schedule to the (system thruput) bottleneck". misc. past posts mentioning past dynamic adaptive scheduling work and-or the resource manager

previous posts in this thread:

misc past posts mentioning os-vs2 starting out using CCWTRANS from cp67