There is handshaking between Linux and VM, and even more than one flavor....
The fact that z/VM still likes to have some expanded storage is that the management of central and expanded are different: For expanded, CP has a time stamp and know exactly how old each page is. For central storage there only is the reference bit, thus CP can only know if the page was referenced since the last scan. 2010/9/24 George Henke/NYLIC <george_he...@newyorklife.com> > > > Anne & Lynn Wheeler wrote: > > <Their is a > <pathological scenario if the virtual operation doesn't have all its > <own dedicated storage (like in LPARs); VM will be managing virtual > <pages using an LRU methodology (least-recently-used pages are the ones > <selected for replacement) ... at the same time the virtual guest/DBMS > <is also managing (what it thinks is real storage) with an LRU > <methodology. If both are operating simultaneously ... it is possible > <for VM to "replace" what it thinks is the least-recently-used page > <(the virtual page least likely to be used) ... at the same time the > <virtual guest/DBMS has decided that same page is exactly the next page > <it wants to use.> > > > Was not this the problem in the early days of MVS under VM. There was also > a stopgap workaround performance option (bandaid) called PMA, Preferred > Machine Assist to circumvent this, so that MVS actually controlled Page 0 > and VM became the guest. > > VSE did not have this problem in those days because there was the VM/VSE > Feature which did the paging handshake between a VSE guest and VM. > > But MVS had no such feature and so the entire MVS virtual machine got > swapped out any time an address space in MVS got a page hit. > > But these issues have all been addressed today and MVS now performs > efficiently under VM. Also, paging now seems to be non-existent in the MVS > world. Expanded storage there even has been eliminated. > > So the question arises why is this problem rearing its head again. > > Is "history repeating itself". Is there no handshaking between LINUX > guests and VM just as there was not with MVS years ago? > > Why now the need Expanded Storage in the VM world to accommodate LINUX > guests when Expanded Storage in the MVS world is a thing of the past? > > > > > > *Anne & Lynn Wheeler <l...@garlic.com>* > Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> > > 09/24/2010 08:02 AM > Please respond to > The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> > > To > IBMVM@LISTSERV.UARK.EDU > cc > Subject > Re: Central vs. expanded storage > > > > > On Thu, Sep 23, 2010 at 2:14 AM, O'Brien, Dennis L > <dennis.l.o'br...@bankofamerica.com <dennis.l.o%27br...@bankofamerica.com>> > wrote: > >I heard from a couple of performance people at SHARE that we should have > >20% to 25% of the total storage in an LPAR configured as expanded > >storage. Naturally, that's a guideline and the proper amount varies by > >workload. What should I look at to determine if we have enough expanded > >storage? We use Velocity's ESALPS suite. The systems that I'm most > >concerned about have a Linux guest workload. One of them is all WAS, > >and the other is a mix of WAS, Oracle, and some other things. > > > >I've heard that WAS isn't the best choice for System z, but that's not > >the focus of my concern. We have the workload that we have, and I just > >want to make it run as well as it can. > > expanded store was originally done for 3090 because of physical > packaging problems ... it was not possible to locate all the memory > they needed for configuration within the latency of the standard > memory bus ... so they created the expanded store bus that was wider & > longer ... and used software control to move 4k pages back&forth > between regular storage and expanded store. a synchronous instruction > was provided for moving the data back&forth. > > the expanded store bus was also used to attach HIPPI (100mbyte/sec) > channel/devices ... since the standard 3090 i/o interface couldn't > handle the data-rate. However, since bus didn't support channel > programs ... there was a peculiar (pc-liked) peek/poke convention used > (i.e. i/o control was done by moving 4k blocks to/from special > reserved addresses on the bus). > > moving forward (after physical packaging was no longer an issue) > ... expanded store paradigm has been preserved because of software > storage management &/or storage addressing deficiencies. > > effectively, expanded store paradigm is used to partition real storage > into different classes .... however, going back at least 40yrs > ... there is large body of data that shows that single large store is > more efficient than partitioning the same amount of storage (assuming > that there aren't other storage management issues/shortcomings). > > the simple scenario is 10000 storage pages and 10000 expanded storage > pages ... all occupied; when there is requirement for page that is in > expanded storage, it is swapped with a page in regular storage > (incurring some software overhead). The alternative is one large block > of 20000 pages ... all directly executable ... and doesn't require > swapping any pages between expanded store and regular store. > > One of the efficiencies is dealing with application and/or operating > systems that perform their own caching/paging algorithm using some > sort of LRU mechanism (i.e. replacing their own pages/records using > some approximation to least-recently-used). This is characteristic of > large DBMS infrastructures that manage records in their own cache as > well as operating systems that support virtual memory. Their is a > pathological scenario if the virtual operation doesn't have all its > own dedicated storage (like in LPARs); VM will be managing virtual > pages using an LRU methodology (least-recently-used pages are the ones > selected for replacement) ... at the same time the virtual guest/DBMS > is also managing (what it thinks is real storage) with an LRU > methodology. If both are operating simultaneously ... it is possible > for VM to "replace" what it thinks is the least-recently-used page > (the virtual page least likely to be used) ... at the same time the > virtual guest/DBMS has decided that same page is exactly the next page > it wants to use. > > Executing LRU replacement algorithms in a virtual guest/DBMS ... where > its storage is also being managed via an LRU replacement algorithm, > ... can invalidate the assumption underlying LRU replacement > algorithms ... that the least-recently-used page is the least likely > to be used (a virtual guest/DBMS ... doing is own LRU algorithm is > likely to select the least-recently-used page as the next page most likely > to be used). > > misc. past posts mentioning expanded store > http://www.garlic.com/~lynn/2000c.html#61 TF-1 > > <http://www.garlic.com/%7Elynn/2000c.html#61>http://www.garlic.com/~lynn/2001k.html#73 > Expanded Storage? > > <http://www.garlic.com/%7Elynn/2001k.html#73>http://www.garlic.com/~lynn/2001k.html#74 > Expanded Storage? > > <http://www.garlic.com/%7Elynn/2001k.html#74>http://www.garlic.com/~lynn/2002e.html#8 > What are some impressive page rates? > > <http://www.garlic.com/%7Elynn/2002e.html#8>http://www.garlic.com/~lynn/2004e.html#2 > Expanded Storage > > <http://www.garlic.com/%7Elynn/2004e.html#2>http://www.garlic.com/~lynn/2004e.html#3 > Expanded Storage > > <http://www.garlic.com/%7Elynn/2004e.html#3>http://www.garlic.com/~lynn/2004e.html#4 > Expanded Storage > > <http://www.garlic.com/%7Elynn/2004e.html#4>http://www.garlic.com/~lynn/2006.html#13 > VM maclib reference > > <http://www.garlic.com/%7Elynn/2006.html#13>http://www.garlic.com/~lynn/2006.html#38 > Is VIO mandatory? > > <http://www.garlic.com/%7Elynn/2006.html#38>http://www.garlic.com/~lynn/2006b.html#14 > Expanded Storage > > <http://www.garlic.com/%7Elynn/2006b.html#14>http://www.garlic.com/~lynn/2006b.html#15 > {SPAM?} Re: Expanded Storage > > <http://www.garlic.com/%7Elynn/2006b.html#15>http://www.garlic.com/~lynn/2006b.html#16 > {SPAM?} Re: Expanded Storage > > <http://www.garlic.com/%7Elynn/2006b.html#16>http://www.garlic.com/~lynn/2006b.html#17 > {SPAM?} Re: Expanded Storage > > <http://www.garlic.com/%7Elynn/2006b.html#17>http://www.garlic.com/~lynn/2006b.html#18 > {SPAM?} Re: Expanded Storage > > <http://www.garlic.com/%7Elynn/2006b.html#18>http://www.garlic.com/~lynn/2006b.html#34 > Multiple address spaces > > <http://www.garlic.com/%7Elynn/2006b.html#34>http://www.garlic.com/~lynn/2006c.html#1 > Multiple address spaces > > <http://www.garlic.com/%7Elynn/2006c.html#1>http://www.garlic.com/~lynn/2006k.html#57 > virtual memory > > <http://www.garlic.com/%7Elynn/2006k.html#57>http://www.garlic.com/~lynn/2006r.html#35 > REAL memory column in SDSF > > <http://www.garlic.com/%7Elynn/2006r.html#35>http://www.garlic.com/~lynn/2006r.html#42 > REAL memory column in SDSF > > <http://www.garlic.com/%7Elynn/2006r.html#42>http://www.garlic.com/~lynn/2007o.html#26 > Tom's Hdw review of SSDs > > <http://www.garlic.com/%7Elynn/2007o.html#26>http://www.garlic.com/~lynn/2007o.html#48 > Virtual Storage implementation > > <http://www.garlic.com/%7Elynn/2007o.html#48>http://www.garlic.com/~lynn/2007p.html#11 > what does xp do when system is copying > > <http://www.garlic.com/%7Elynn/2007p.html#11>http://www.garlic.com/~lynn/2008.html#49 > IBM LCS > > <http://www.garlic.com/%7Elynn/2008.html#49>http://www.garlic.com/~lynn/2008b.html#15 > Flash memory arrays > > <http://www.garlic.com/%7Elynn/2008b.html#15>http://www.garlic.com/~lynn/2009d.html#29 > Thanks for the SEL32 Reminder, Al! > > <http://www.garlic.com/%7Elynn/2009d.html#29>http://www.garlic.com/~lynn/2009e.html#54 > Mainframe Hall of Fame: 17 New Members Added > > <http://www.garlic.com/%7Elynn/2009e.html#54>http://www.garlic.com/~lynn/2010i.html#18 > How to analyze a volume's access by dataset > <http://www.garlic.com/%7Elynn/2010i.html#18> > -- Kris Buelens, IBM Belgium, VM customer support
