larrychenev...@verizon.net (Larry Chenevert) writes: > Amdahl had an internal tool that did this.
there were two different simulators done in late 70s ... one used standard i/o vm370 trace and modeled activity. it was modified to take a full 3330 configuration and output the configuration for migration to 3350 ... with load-balancing across 3350 drives. The other was "DMKCOL" (internal mods to vm) which did super high performance cchr capture and drove it various thru cache design and replacement algorithms. There was also work on abstracting the information in real time so that it could be run as part of normal production operation for providing input into dynamic disk allocation. While the initial work was under vm370 ... it was used for capturing information from production cms-intensive operations as well as guest operating systems (under vm370) ... the methodology could be added to other operating systems. Early cache simulation results was looking at optimal placement of fixed amount of electronic storage cache ... i.e. trade-off between disk-level cache, controller level cache, channel level cache, (303x channel) director level cache or system level cache. One of the results was that single system level cache was more efficient than dividing the electronic memory available multiple smaller caches. This result was purely from the standpoint of cache hit ratios and aggregate amount of fixed electronic storage. The limitation at the time (late 70s) was now way to have system level managed addressability for large amounts of cache ... and no easy way to have independent processor managing the information. Even tho it showed that multiple 8mbytes in 3880 controller caches was less efficient (in terms of cache hit ratios) than single large system cache ... there was no easy way of packaging and shipping the system cache (although it might have contributed to justifying expanded store in 3090). I had done a lot of work for DMKCOL ... and it was somewhat satisfying that the different cache level simulation showing that single global cache had higher hit ratio than equivalent electronic storage partitioned into different 3880 controllers. This corresponded to the work I had done as undergraduate in the 60s as undergraudate and showing global replacement was more efficient than local/partitioned replacement. Slightly later I got pulled into academic dispute over global versus local ... there was some amount of concerted opposition to granting a stanford PHD on global replacement. At acm sigops '81 meeting, I was asked to provide supporting evidence on global replacement from my 60s undergraduate days. Presumably some sort of internal corporate politics resulted in my not being allowed to respond until oct82 (sounds better than assuming that they were taking sides in the academic dispute) http://www.garlic.com/~lynn/2006w.html#email821019 in this post: http://www.garlic.com/~lynn/2006w.html#46 a couple past posts mentioning DMKCOL work http://www.garlic.com/~lynn/2006y.html#35 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After Multi-Core? misc. past posts referencing global replacement work http://www.garlic.com/~lynn/subtopic.html#wsclock Longer term DMKCOL collecting (several months) ... after identifying relatively short term use patterns (used for things like cache design) ... started turning up other kinds of longer period patterns ... certain collections of accesses done on periodic basis. some of this shows up backup/archive "containers" ... collections treated as single unit ... I had done the original CMSBACK that then morphed into workstation datasave facility, then ADSM and is now TSM ... some old email http://www.garlic.com/~lynn/lhwemail.html#cmsback misc. past backup/archive posts http://www.garlic.com/~lynn/submain.html#backup -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
