The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[email protected] (Jim Marshall) writes: > And even before then it was a MOD to OS/MVT which I applied in the > late 1970s to an IBM 360-75J which predefined a number of cell pools > to be used for stuff. Thus it avoided having to do a GETMAIN for a > small chunk of storage. After I applied it, I did my standard > Benchmark and it gave me 15- 18% boost in CPU power. Do not remember > if it came out from IBM or some Prehsitoric HACKER. Anyway, IBM made > it standard equipment in MVS along with many of the MODS and zaps > people dreamed up for MVT. With this mod and other modifications I > could outrun an IBM 370-158. OK, so it took a bit more space, power, > and A/C. Invention on cp67 called it subpools for kernel storage ... storage management was becoming an increasingly large percentage of total kernel processor time ... and subpools dropped it way back down. a couple old post http://www.garlic.com/~lynn/2000d.html#47 Charging for time-share CPU time http://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms above includes URL for system journal reference http://domino.research.ibm.com/tchjr/journalindex.nsf/e90fc5d047e64ebf85256bc80066919c/7c6d60f9060c7e7a85256bfa00685a7c?OpenDocumen B. Margolin, et al, Analysis of Free-Storage Algorithms, IBM System Journal 10, pgs 283-304, 1971 Dynamic management of free storage in a time-sharing operating system was studied empirically by the techniques of monitoring, emulation, and on-line experimentation. A new algorithm, based on observed usage patterns of different block sizes, was implemented and evaluated. On-line experiments demonstrated that supervisor time spent in free-storage management was reduced by seven or eight to one. ... snip ... kernel storage had been best-fit on allocation and sorted storage address order on return ... lots of list chaining. All kernel calls had previously been via supervisor call (originally on cp67 had been over 270 microseconds) ... I had replaced high-use kernel subroutine calls (including free storage) with BALR linkage, which showed a significnat improvement in percent kernel processor (originally done when I was spending summer of 1969 at Boeing helping with the formation of Boeing Computer Services). Under high-load, free-storage list following could involve 200-300 items (or more) ... with loop involving several instructions (possibly 10 microseconds per item ... maybe a couple milliseconds per call). subpool could be done in 14 instructions (including BALR linkage) ... if tracing was turned on, generating trace entry for each free storage call nearly doubled the time (approx. another ten instructions). As an aside ... original implementation of VS2/SVS required a little bit of hacking to provide a single virtual address space ... but for the most part SVS was still MVT as if it was running in 16mbyte virtual machine ... except for EXCP. This required scanning & building shadow channel program (effectively the same as was being done in CP67 virtual machine support) ... and they borrowed CCWTRANS (routine that performed the function in CP67) and crafted it into the side of SVS (this was initially being done on 360/67 before 370s with virtual memory support were available). CCWTRANS performance depended heavily on efficiency of kernel storage (so it is likely some similar storage management was hacked into the side of SVS at that time). as implied in 2004 post ... subpool could be done with compare&swap ... w/o requiring lock/unlock paradigm overhead. recent post mentioning compare&swap: http://www.garlic.com/~lynn/2010h.html#14 Posting ECB's, SRB's, Across Region Boundaries - Pre CMS -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
