On Mon, 4 Feb 2008 15:54:23 -0600, Kelman, Tom wrote: >Tom, > >What you and others have said here has really got me thinking. It's >been about 20 years since I was really an MVS System Programmer getting >into the bowels of the operating system. I've been a performance tuner >and now a capacity planner for many years. However, what has been said >here about the variability of CPU time seems to through all my ideas >about capacity planning and charge back algorithms out the window.
Ahh.... Charge back. That's a difficult subject. Still, you need not necessarily throw much of it out. The effects that I was describing might be difficult to show. If I were to try to demonstrate these effects on a z9 BC, here's ow I'd set up a test. First, I'd need an LPAR with an extremely low weight. Perhaps a weight of 1 with the other LPARs adding up to a few hundred. My test LPAR would get very poor service indeed. I'd load down my other LPARs with programs that would not do any I/O and that would reference a *lot* of storage. The BC has 256K of data cache and 256K of instruction cache on each PU. In addition, there is 40 MB of Level 2 cache on the MCM. I'd have each of these programs reference enough memory to (probably) use every line in secondary cache, perhaps by dividing a 40 MB area into two 20 MB sections and moving data back and forth between them. I'd run several of these on my high weight LPARs, at least as many as there were LPs on each partition. I'd run a few on the low weight partition, too, but there I'd make sure that they had a lower priority than my test program. The test program would reference a byte of memory at 64 byte intervals over a range of perhaps 64K. Then it would issue a STIMER WAIT. A few seconds should be sufficient. During the time that it was waiting, its cache would tend to all be stolen and the next time it would have to go to main store again. It might take a few thousand iterations to use enough CPU to be measurable. Repeat the test on a lightly loaded LPAR with little memory contention from other LPARs and I'm sure it would use considerably less CPU time. -- Tom Marchant ---------------------------------------------------------------------- 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
