>Our workload is entirely for development. Since we can't predict where demand >will come from we share all of the CPs so that capacity will float to where >it's >needed. One disadvantage is that this is bad for the cache(s). In our >environment >the cost is acceptable. I wouldn't do this if we ran a production workload.
This is a handy question. How is your logical-to-physical CP ratio? And how high is your 'lpar overhead' (type70 SMF) ? We run on z196 and have a 18 logicals to 4 physicals ratio (4.5:1), with lpar overhead on these (slowed down) GCPs reaching 2% at the most. The other box runs 12:4 (3:1), with lpar overhead around 0.8%. No Hiperdispatch. Would Hiperdispatch even run in a 4,5:1 ratio environment? Or would it throw in the towel and turn itself off? We also run IFLs, and the picture here is drastically different. On the IFLs we run 18 logicals on 8 physicals and 20:8 (2,5:1) on the other box. The IFLs are obviously not slowed down. LPAR overhead for IFLs on the 20:8 box is near 3% at times, and around 1.5% on the other. Has anyone else any numbers for a z196 with similar logical-to-physical ratios? I am always surprised about how high lpar overhead on the IFLs is. Is VM doing anything extra with regard to lpar overhead that an MVS wouldn't do? (The linuxes running under each VM are also grossly overspecified in their 'logical' processor specs, which *should* show up as overhead within that VM lpar (vm monitor). I have been wondering if some of that overhead is given out to general lpar overhead. Or is it just that the high speed of the IFLs (compared to our slowed-down GCPs) causes this overhead? Thanks, Barbara NItz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
