The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
re: http://www.garlic.com/~lynn/2010e.html#75 LPARs: More or Less? basically SIE greatly expanded the architecture definition for virtual machine mode ... as addition/alternative to real machine mode ... aka principle of operations defines a lot of stuff about how things operate in real machine mode ... "virtual machine mode" makes various changes ... like what are the rules for supervisor & problem state when running in virtual machine mode; it greatly increased performance of running in virtual machine mode (compared to full software simulation) ... modulo 3081 choosing to have the service processor page the SIE microcode on 3310 FBA device ... recent ref http://www.garlic.com/~lynn/2010e.html#34 Need tool to zap core now one of the big guest performance hits to vm370 was transition from svs to mvs ... because the number of times that MVS changed CR1 exploded (compared to svs) ... requiring vm370 to flush the shadow page tables each time (virtual machine changed its "virtual" cr1). now one of the things that could be done in a SIE scenario is to change the operation of TLB miss/reload in virtual machine mode ... so that hardware performed the double lookup on TLB miss ... eliminating the requirement for having shadow tables (instead of having to maintain the shadow table information ... which then is significantly amount of overhead in flush scenario ... whether explicit via "virtual" PTLB or implicit by change in "virtual" CR1 value). As SIE began to blanket nearly ever aspect of machine operation ... with the "virtual machine" flavor ... it greatly simplified the introduction of LPARs. there use to be some SHARE thing about the greatly increasing MVS bloat ... one was scenario about creeping processor bloat ... possibility of waking up one day and MVS was consuming all processor cycles with none left for applications. This was somewhat the capture ratio scenario where the amount of processor cycles even being accounted for, falling below 50%. The san jose plant site highlighted a 70% capture ratio of MVS system dedicated to apl ... but the apl subsystem was doing nearly everything possible to avoid using any MVS system services as method of improving thruput and performance. recent capture ratio mention http://www.garlic.com/~lynn/2010e.html#33 SHAREWARE at Its Finest The creeping bloat of common segment area size was similar ... threatening to totally consume the remaining 16mbyte virtual address space ... leaving nothing for applications to run. The dual-address space introduction in 3033 was an attempt to at least slow down the creeping common segment size bloat (threatening to totally consume all available virtual address space). -- 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
