originally cp67 had everything in the kernel, booted and fixed in real memory, there were a pre-allocated fix number of save areas for kernel linkage (making it slightly easier to identify everything going on from a dump ... so all saveareas were in contiguous area of storage), and total kernel dynamically allocated working storage (all the kernel control blocks, virtual i/o structure, virtual memory, working storage, etc) could increase by making calls to paging supervisor
as undergraduate, i did a lot of work on dynamic adaptive scheduling and graceful degradation with increasing work load. increasing work load ... could exhaust the pre-allocate kernel linkage save areas ... so i had to make change to allow for kernel linkage save areas to dynamically increase (decrease) in much the same way the rest of kernel dynamically allocated storage could increase/decrease. this became part of the distributed cp67 kernel there was a lot of stuff in the cp67 kernel that was relatively low useage ... like various commands, and with increasing work load, there was lot more pressure on available real storage ... a 786k 360/67, 64 pages per 256k ... might only have 110-120 pages after fixed kernel requirements; being able to "page-out" low-useage kernel components might pick up 15-20percent real storage for workload. this didn't ship in the standard kernel until vm370. there was an issue with the free storage manager doing a generalized call to the paging supervisor for additional working storage. the paging supervisor could sometimes select a modified virtual memory page for replacement ... this would require scheduling a page i/o write for the page and waiting for the i/o to complete before making it available for kernel use (during that period the system would sometimes crash because of lockup and exhausted working storage). i created a special page replacement interface for the kernel storage manager ... that would look for any non-changed/non-modified page for replacement (eliminating any delay in extending kernel working storage by scavenging paging memory). this went out in standard cp67 product. for a little drift ... also as an undergraduate i complete redid the page replacement algorithm ... implementing global LRU based on page reference bits ... lots of past postings discussing page replacement algorithms http://www.garlic.com/~lynn/subtopic.html#wsclock lots of these factors contribute to what appears to be amount of real memory that is associated with the kernel ... and therefor the amount of spool space that may be required for containing a "dump" of kernel real storage image. for other topic drift ... lots of past postings mentioning problem failure/diagnostic http://www.garlic.com/~lynn/subtopic.html#dumprx much, much later ... i had an issue with the aggregate thruput that a single virtual machine could get out of the spool file interface. part of the issue was that spool buffer transfers were syncronous ... during which time the virtual machine didn't process. recent posts in this n.g. http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow http://www.garlic.com/~lynn/2006s.html#20 real core mentioning hsdt effort. part of this was vnet/rscs driving multiple HYPERchannel links ... some channel speed links on the same machine room (couple mbytes/sec) and a number of full duplex T1 links (about @300kbytes/sec aggregate per link). the synchronous nature of the spool interface limited vnet/rscs to between 5-10 4k spool buffers/sec (depending on other load for the spool system) ... or 20kbytes/sec under most loads to possibly max of 40kbytes/sec. HSDT needed aggregate spool thruput closer to 100 times that. so my effort was to move most of the spool function into a virtual address space, completely recode it in pascal/vs, and provide significant additional asynchronous behavior (to increase aggregate thruput by two orders of magnitude). recent post discussing the change http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's part of the implementation running spool function in virtual address space was taking advantage of the page map interface that i had done originally in the early 70s for cp67 cms page mapped filesystem http://www.garlic.com/~lynn/subtopic.html#mmap also part of hsdt backbone was doing rfc1044 support for the mainframe tcp/ip implementation (which shipped in the product). the base tcp/ip support would consume nearly a full 3090 processor getting aggregate 44kbytes/sec thruput. in some tuning/testing at cray research, between 4341 clone and cray ... rfc1044 was getting sustained channel interface thruput (1mbyte/sec) using only modest amount of the 4341 clone processor. http://www.garlic.com/~lynn/subnetwork.html#1044
