3090 service processor & 370 virtual memory (long winded x-over from ibm-main)
re: http://www.garlic.com/~lynn/2009r.html#18 "Portable" data centers the modifications for vm370 release 6 to be service processor started well before 3090 came out. it was a copy of standard vm370 release 6 (predates vm/sp) and then "frozen" (with respect to the standard product) and then various enhancements added ... like interfaces to all the diagnostic hardware that was going to be in the 3090. i provided some number of tools and other stuff, supporting the effort. Some of the stuff was things I had done for the disk engineering & product test labs ... to eliminate large class of failures (they had been running stand-alone with trivial monitor ... after having tried to use MVS and experienced 15min MTBF with a single "testcell"): http://www.garlic.com/~lynn/subtopic.html#disk At the time they had started the effort ... they gathered up as much stuff as they could ... anticipating that vm370 release 6 ... would not be current thru the lifetime of the 3090; TROUT ... some past posts with other old email from TROUT period: http://www.garlic.com/~lynn/2006j.html#27 virtual memory http://www.garlic.com/~lynn/2006j.html#31 virtual memory i was blamed for online computer conferencing on the internal network in the late 70s and early 80s. The POK engineering manager that headed up the 3090 service processor ... had observed all the issues with the 3081 service processor ... having to write everything from scratch and was a big proponent of using as much as possible readily available tools (i.e. 3090 service processor screens were actually CMS IOS3270). In any case, the guy heading up the effort also became somewhat active in some of the computer conferencing and took some amount of hits for the activity (although not nearly as much as I did). He also took hits on scope-creep in the effort and growing demand for people and resources. DOS Emulator feature had base/bound (significantly simpler than all the segment and page table stuff; just check the address against the "bound" ... and then add in the "base") ... not for paging but for address translation ... like some LPAR implementations ... still required a contiguous amount of real-memory. I was undergraduate in the 60s ... but still doing a lot of work on both os/360 (responsible for academic and administrative system at the univ. ... including doing highly customized os/360 system for careful placement of datasets and PDS members to optimize arm seek & getting approx three times thruput improvement for student jobs). I was also allowed to do a lot of cp67 ... rewritting lots of the kernel code. Anycase, recent posts about Boeing trying to move all of their dataprocessing into BCS (fledging BCS started out in boeing corporate hdqtrs administrative ... which had single 360/30 for payroll): http://www.garlic.com/~lynn/2009r.html#43 Boeings New Dreamliner Ready For Maiden Voyage http://www.garlic.com/~lynn/2009r.html#44 Boeings New Dreamliner Ready For Maiden Voyage http://www.garlic.com/~lynn/2009r.html#45 Boeings New Dreamliner Ready For Maiden Voyage and I got dragged into it. I was con'ed into giving one week class (during spring break, '69) to the fledging BCS technical staff (and the ibm technical support team). I was then brought in as full-time BCS employee for the summer of '69. Part of responsibility was installing cp67 operation in corporate hdqtrs machine room (which until then just had a 360/30 for payroll). Part of BCS was to take over the renton datacenter (a little corporate internal politics) ... which was the largest operation I had seen ... summer of '69 there were always pieces for 2-3 360/65s staged around in the hallways ... because 360/65s were arriving faster than they could be installed. In any case, after 370s were available ... but not yet with virtual memory support ... one of the IBM SEs on the boeing account did a "hacked" version of cp67 to use 370 DOS Emulator (aka address base+bound, contiguous real storage) ... again much more like LPAR support. He did do complete swap of a virtual machine address space (i.e. virtual machine size had to match the base+bound contiguous area) ... so could run more virtual machines that there was total real storage available. As mentioned in the above ... summer of '69 ... Boeing also moved the 360/67 multiprocessor from Huntsville to Seattle (this was separate from the 360/67 uniprocessor installed in corporate hdqtrs). Huntsville had been using it to run a highly modified version of MVT release 13. Problem was that MVT had significant problem with storage fragmentation with long running jobs. Huntsville had a large collection of 2250s with long running graphics application. Hack to MVT was to use the 360/67 address translation hardware to re-arrange real storage to appear "contiguous" (no paging) ... this was different than the early 370 hack to cp67 to use the base+bound (
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Thu, 7 Aug 2008 12:53:03 -0500, Bill Holder <[EMAIL PROTECTED]> wrote : >On Thu, 7 Aug 2008 12:51:21 -0500, Bill Holder <[EMAIL PROTECTED]> wrot e: > > = = >> >>Yes, I did saw that and meant to respond but forgot. The current support >>does not include dynamic increase for xstore. That's an interesting >>argument for considering it (that dynamically added xstore could then b e >>more easily dynamically detached, which is certainly true enough). I'm not >>how widely applicable that support would be nor far that would go towards >>addressing Richard's needs, though. Still, it would allow them to make some >>sort of use of the otherwise idle storage. >> >>- Bill Holder, z/VM Development, IBM > >Ooops - Next to last sentence should read: "I'm not >>sure<< how". It's a VM LPAR he wants to add and remove the storage from. At his baseline level of storage he has some level of paging to real DASD. Adding XSTORE would reduce that. Alternativley, if his current level of paging is low or none, the extra XSTORE would allow additional servers to be brought up without driving up the paging to real DASD. If that doesn't help him (or anyone) then they have no real need to add more storage to a VM LPAR in the first place. He seems to think the extr a storage would benefit his VM LPAR, otherwise he would/should have said that adding storage wouldn't help him and thus make part of this discussion moot. While getting additional storage as normal storage is better than getting it as XSTORE, getting it as XSTORE is still a pretty good deal especially when you consider the relative ease of removing XSTORE vs removing regula r storage. Brian Nielsen
Re: ADD VIRTUAL MEMORY DYNAMICALLY
A variant of Mike's idea would be to specify by SYSTEM CONFIG parm a "ceiling" beyond which SXS would not be allocated. You could then IPL a system with a given amount of storage, and subsequently take some away, down as far as the previously-set ceiling. Mark Wheeler, 3M Company Bill Holder <[EMAIL PROTECTED] OM>To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System <[EMAIL PROTECTED] Subject ARK.EDU> Re: ADD VIRTUAL MEMORY DYNAMICALLY 08/07/2008 11:48 AM Please respond to The IBM z/VM Operating System <[EMAIL PROTECTED] ARK.EDU> On Wed, 6 Aug 2008 16:25:27 -0700, Mike Harding <[EMAIL PROTECTED]> wrote: ... > >An alternative - which might even satisfy Mr. Schuh - could be to restrict >"detachable" memory to that which has been dynamically added after CP was >iplled. I wouldn't think the SXS would extend into such, which would make >it easier to clear. Of course it's been a while since I did much perusing >of CP internals... >--Mike >= Yes, that simplifies it somewhat, wouldn't require pre-definition of the detachable range, but it still means rewriting pretty much all of storage allocation to know certain areas are restricted and need to be managed separately, and all allocation logic would need to be additionally multi-pathed based on request type. Not a trivial undertaking by any means, but feasible enough, I suppose, if enough customers were to ask for it to be made a priority over other functions already being requested. - Bill Holder, z/VM Development, IBM
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Thu, 7 Aug 2008 12:51:21 -0500, Bill Holder <[EMAIL PROTECTED]> wrote : = = > >Yes, I did saw that and meant to respond but forgot. The current suppor t >does not include dynamic increase for xstore. That's an interesting >argument for considering it (that dynamically added xstore could then be >more easily dynamically detached, which is certainly true enough). I'm not >how widely applicable that support would be nor far that would go toward s >addressing Richard's needs, though. Still, it would allow them to make some >sort of use of the otherwise idle storage. > >- Bill Holder, z/VM Development, IBM Ooops - Next to last sentence should read: "I'm not >>sure<< how". - Bill Holder, z/VM Development, IBM
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Thu, 7 Aug 2008 11:59:33 -0500, Brian Nielsen <[EMAIL PROTECTED]> wrote: ... > > > >Did you see my post yesterday regarding XSTORE? I've included it below. > >Brian Nielsen > ... > = === Yes, I did saw that and meant to respond but forgot. The current support does not include dynamic increase for xstore. That's an interesting argument for considering it (that dynamically added xstore could then be more easily dynamically detached, which is certainly true enough). I'm n ot how widely applicable that support would be nor far that would go towards addressing Richard's needs, though. Still, it would allow them to make s ome sort of use of the otherwise idle storage. - Bill Holder, z/VM Development, IBM
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Thu, 7 Aug 2008 11:48:24 -0500, Bill Holder <[EMAIL PROTECTED]> wrote : >On Wed, 6 Aug 2008 16:25:27 -0700, Mike Harding <[EMAIL PROTECTED]> wrote: > > >... >> >>An alternative - which might even satisfy Mr. Schuh - could be to restrict >>"detachable" memory to that which has been dynamically added after CP w as >>iplled. I wouldn't think the SXS would extend into such, which would make >>it easier to clear. Of course it's been a while since I did much perusing >>of CP internals... >>--Mike >> = > >Yes, that simplifies it somewhat, wouldn't require pre-definition of the >detachable range, but it still means rewriting pretty much all of storag e >allocation to know certain areas are restricted and need to be managed >separately, and all allocation logic would need to be additionally >multi-pathed based on request type. Not a trivial undertaking by any means, >but feasible enough, I suppose, if enough customers were to ask for it t o be >made a priority over other functions already being requested. > >- Bill Holder, z/VM Development, IBM > = === Did you see my post yesterday regarding XSTORE? I've included it below. Brian Nielsen On Wed, 6 Aug 2008 16:58:40 -0500, Brian Nielsen <[EMAIL PROTECTED]> wrote: >Perhaps I'm missing something, but doesn't XSTORE already meet those >criteria? If so, adding the new storage as XSTORE to the LPAR and later >removing said XSTORE from the LPAR is a much simpler task.
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Wed, 6 Aug 2008 16:25:27 -0700, Mike Harding <[EMAIL PROTECTED]> w rote: ... > >An alternative - which might even satisfy Mr. Schuh - could be to restri ct >"detachable" memory to that which has been dynamically added after CP wa s >iplled. I wouldn't think the SXS would extend into such, which would ma ke >it easier to clear. Of course it's been a while since I did much perusi ng >of CP internals... >--Mike > = Yes, that simplifies it somewhat, wouldn't require pre-definition of the detachable range, but it still means rewriting pretty much all of storage allocation to know certain areas are restricted and need to be managed separately, and all allocation logic would need to be additionally multi-pathed based on request type. Not a trivial undertaking by any mea ns, but feasible enough, I suppose, if enough customers were to ask for it to be made a priority over other functions already being requested. - Bill Holder, z/VM Development, IBM
Re: ADD VIRTUAL MEMORY DYNAMICALLY
To be able to increase memory temporarily to get past a period of unusually high demand. As has been pointed out in the thread, TPF shops invariably have to reserve several GB of memory for native test systems that are seldom used. If that storage could be added temporarily, it could be a real benefit. The problem is, it takes LPAR deactivation/activation to remove it once added. So it is possible to borrow the memory without taking an outage; however, the same is not true of returning it. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of HARROP, Roy > Sent: Thursday, August 07, 2008 1:19 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: FW: ADD VIRTUAL MEMORY DYNAMICALLY > > Am I missing something here? The subject matter is "Add > Virtual Memory > Dynamically", which has got to be a function worth having - > but why would anyone want to remove it? > > Surely it's akin to being able to add packs for paging - and > you can't take them away (cue for a song?). > > This may be half a loaf, but even if it were just one slice, > it's got to be a good feature. The forum thread did make > interesting reading though... > > Regards, > > Roy Harrop > --- > > > -Original Message- > From: Mike Harding [mailto:[EMAIL PROTECTED] > Sent: 07 August 2008 00:25 > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > The IBM z/VM Operating System wrote on > 08/06/2008 03:40:56 PM: > > > On Wed, Aug 6, 2008 at 11:48 PM, Bill Holder <[EMAIL PROTECTED]> > wrote: > > > > > Just to emphasize the point - the fact that most of CP's > storage is > now > > > mapped into virtual(the System Execution Space) is really > irrelevant > > to the > > > question of detaching memory. Although that mapping is indeed > the"default" > > > > I did not mean to make it sound easy. Being able to page it > would be a > > much harder one that being able to move it. At least we > don't need to > > walk all control blocks for pointers to the blocks in the > page that we > > moved. But you still need everyone out of the way when you move it > > (unless that is an atomic operation). > > -Rob > > An alternative - which might even satisfy Mr. Schuh - could > be to restrict "detachable" memory to that which has been > dynamically added after CP was iplled. I wouldn't think the > SXS would extend into such, which would make it easier to > clear. Of course it's been a while since I did much perusing > of CP internals... > --Mike > - > ***If > you are not the intended recipient, please notify our Help > Desk at Email [EMAIL PROTECTED] immediately. You should > not copy or use this email or attachment(s) for any purpose > nor disclose their contents to any other person. NATS > computer systems may be monitored and communications carried > on them recorded, to secure the effective operation of the > system and for other lawful purposes. Please note that > neither NATS nor the sender accepts any responsibility for > viruses or any losses caused as a result of viruses and it is > your responsibility to scan or otherwise check this email and > any attachments. NATS means NATS (En Route) plc (company > number: 4129273), NATS (Services) Ltd (company number > 4129270), NATSNAV Ltd (company number: 4164590) or NATS Ltd > (company number 3155567) or NATS Holdings Ltd (company number > 4138218). All companies are registered in England and their > registered office is at 5th Floor, Brettenham House South, > Lancaster Place, London, WC2E 7EN. > ** > >
FW: ADD VIRTUAL MEMORY DYNAMICALLY
Am I missing something here? The subject matter is "Add Virtual Memory Dynamically", which has got to be a function worth having - but why would anyone want to remove it? Surely it's akin to being able to add packs for paging - and you can't take them away (cue for a song?). This may be half a loaf, but even if it were just one slice, it's got to be a good feature. The forum thread did make interesting reading though... Regards, Roy Harrop --- -Original Message- From: Mike Harding [mailto:[EMAIL PROTECTED] Sent: 07 August 2008 00:25 Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY The IBM z/VM Operating System wrote on 08/06/2008 03:40:56 PM: > On Wed, Aug 6, 2008 at 11:48 PM, Bill Holder <[EMAIL PROTECTED]> wrote: > > > Just to emphasize the point - the fact that most of CP's storage is now > > mapped into virtual(the System Execution Space) is really irrelevant to the > > question of detaching memory. Although that mapping is indeed the"default" > > I did not mean to make it sound easy. Being able to page it would be a > much harder one that being able to move it. At least we don't need to > walk all control blocks for pointers to the blocks in the page that we > moved. But you still need everyone out of the way when you move it > (unless that is an atomic operation). > -Rob An alternative - which might even satisfy Mr. Schuh - could be to restrict "detachable" memory to that which has been dynamically added after CP was iplled. I wouldn't think the SXS would extend into such, which would make it easier to clear. Of course it's been a while since I did much perusing of CP internals... --Mike - ***If you are not the intended recipient, please notify our Help Desk at Email [EMAIL PROTECTED] immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose their contents to any other person. NATS computer systems may be monitored and communications carried on them recorded, to secure the effective operation of the system and for other lawful purposes. Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses caused as a result of viruses and it is your responsibility to scan or otherwise check this email and any attachments. NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd (company number 4129270), NATSNAV Ltd (company number: 4164590) or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). All companies are registered in England and their registered office is at 5th Floor, Brettenham House South, Lancaster Place, London, WC2E 7EN. **
Re: ADD VIRTUAL MEMORY DYNAMICALLY
>Do people really have Linux systems that run 7 x 24? Yes, silly people want to withdraw money (legit or illegit) at any hour of the day or night from an ATM. But Jim should have just bought another z10 and put those with continuous availability (a.k.a. 24x7x365) requirements on duplicate servers on different boxes rather than having IBM add him a feachur ;). Kidding, Jim - dynamic memory is a *good thing* especially if z/OS can do it too :) WebSphere clustering, DB2 HADR, Oracle Data Guard... All those things and more make it possible. Planned outages happen here nearly every weekend (not that that is desirable either :) Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Tuesday, August 05, 2008 11:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] ADD VIRTUAL MEMORY DYNAMICALLY On Tue, 5 Aug 2008 09:58:58 -0700, Schuh, Richard <[EMAIL PROTECTED]> wrote= : >Yes, it can add, but not subtract without LPAR deactivation. Let me >know= >when the ability to dynamically remove previously added storage is >available, and I will be more enthusiastic. > >Regards, >Richard Schuh Deleting memory is a lot harder. What if there are control blocks in there? You could use handles (pointer= s to pointers) but that is a complete rewrite. If a control block can move, you cannot trust a registe= r to continue to point to it. I think this would require a new instruction set to do the pointer to= pointer resolution directly. Or you can fence off areas and say "no control blocks allowed in here". T= hat would increase the complexity of operating systems, though. Such storage could only be used = to back up guest or pageable operating system pages. If you wanted to remove a block of memory, you would have to initiate a m= ass page-out to clear the area. I'd rather not have to resolve the performance issues that migh= t occur. Does z/OS do this? I don't think the ability to remove memory is something I want IBM to spe= nd scarce z/VM development dollars on. Another thought: The need to add memory may be an emergency situation. The need to remove = it again is not an emergency and can be planned. How important avoiding an IML may be depend= s on whether you really want to achieve 7 x 24 operation. 7 x 24 operation is going to cos= t you something -- including adequate capacity and memory. There are other ways to achieve 7 x 24 operation. We don't run any system= s with true 7 x 24 requirements. We may run pairs of systems, or sysplexes of systems, but n= ot single systems. Do people really have Linux systems that run 7 x 24? Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: ADD VIRTUAL MEMORY DYNAMICALLY
The IBM z/VM Operating System wrote on 08/06/2008 03:40:56 PM: > On Wed, Aug 6, 2008 at 11:48 PM, Bill Holder <[EMAIL PROTECTED]> wrote: > > > Just to emphasize the point - the fact that most of CP's storage is now > > mapped into virtual(the System Execution Space) is really irrelevant to the > > question of detaching memory. Although that mapping is indeed the"default" > > I did not mean to make it sound easy. Being able to page it would be a > much harder one that being able to move it. At least we don't need to > walk all control blocks for pointers to the blocks in the page that we > moved. But you still need everyone out of the way when you move it > (unless that is an atomic operation). > -Rob An alternative - which might even satisfy Mr. Schuh - could be to restrict "detachable" memory to that which has been dynamically added after CP was iplled. I wouldn't think the SXS would extend into such, which would make it easier to clear. Of course it's been a while since I did much perusing of CP internals... --Mike
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Wed, Aug 6, 2008 at 11:48 PM, Bill Holder <[EMAIL PROTECTED]> wrote: > Just to emphasize the point - the fact that most of CP's storage is now > mapped into virtual(the System Execution Space) is really irrelevant to the > question of detaching memory. Although that mapping is indeed the "default" I did not mean to make it sound easy. Being able to page it would be a much harder one that being able to move it. At least we don't need to walk all control blocks for pointers to the blocks in the page that we moved. But you still need everyone out of the way when you move it (unless that is an atomic operation). -Rob
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Wed, 6 Aug 2008 16:48:13 -0500, Bill Holder <[EMAIL PROTECTED]> wrote : >On Wed, 6 Aug 2008 09:17:24 +0200, Rob van der Heij <[EMAIL PROTECTED]> wrote: > >>On Wed, Aug 6, 2008 at 8:06 AM, Alan Ackerman >><[EMAIL PROTECTED]> wrote: >> >>> Deleting memory is a lot harder. >> >>Many delicate CP areas now also are in virtual memory as a result of >>the 2G relief, even though not all may be paged. >>It depends a lot on the granularity of the next level of mapping. When >>90% of your in-use pages is virtual machine pages, you can probably >>find 16 MB worth of individual pages to give up. But evacuating pages >>at random in the hope to free an entire 16MB chunk is less attractive >>(I think some time ago pages under the bar would be freed like that). >> >... >> >>Rob >> = > >Just to emphasize the point - the fact that most of CP's storage is now >mapped into virtual(the System Execution Space) is really irrelevant to the >question of detaching memory. Although that mapping is indeed the "default" >CP storage usage and CP code has to go "out of its way" to touch real >storage directly, all SXS mappings are defined to be static at least for the >duration of the usage, and many (like the nucleus and prefix areas) are >outright permanent. A CP thread having rights to a given SXS virtual >address gives it implicit rights for the same duration to the real address >backing it. > >So I basically agree with Alan's two choices - either we'd have to rewrite >virtually everything to tolerate pageable (or at least re-assignable) CP >storage, or we'd have to rewrite all of storage allocation to know that >there's an area that might have to be depopulated on demand at some poin t in >the future, such that only truly pageable uses can be allocated out of it. >The latter approach is certainly simpler, but also more restrictive, >requiring pre-planning and definition of the area subject to later removal. >Quite a lot of work, and more than a few nasty complications, either way. > >- Bill Holder, z/VM Development, IBM Perhaps I'm missing something, but doesn't XSTORE already meet those criteria? If so, adding the new storage as XSTORE to the LPAR and later removing said XSTORE from the LPAR is a much simpler task. Brian Nielsen
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Wed, 6 Aug 2008 09:17:24 +0200, Rob van der Heij <[EMAIL PROTECTED]> w rote: >On Wed, Aug 6, 2008 at 8:06 AM, Alan Ackerman ><[EMAIL PROTECTED]> wrote: > >> Deleting memory is a lot harder. > >Many delicate CP areas now also are in virtual memory as a result of >the 2G relief, even though not all may be paged. >It depends a lot on the granularity of the next level of mapping. When >90% of your in-use pages is virtual machine pages, you can probably >find 16 MB worth of individual pages to give up. But evacuating pages >at random in the hope to free an entire 16MB chunk is less attractive >(I think some time ago pages under the bar would be freed like that). > ... > >Rob > = Just to emphasize the point - the fact that most of CP's storage is now mapped into virtual(the System Execution Space) is really irrelevant to t he question of detaching memory. Although that mapping is indeed the "defau lt" CP storage usage and CP code has to go "out of its way" to touch real storage directly, all SXS mappings are defined to be static at least for the duration of the usage, and many (like the nucleus and prefix areas) are outright permanent. A CP thread having rights to a given SXS virtual address gives it implicit rights for the same duration to the real addres s backing it. So I basically agree with Alan's two choices - either we'd have to rewrit e virtually everything to tolerate pageable (or at least re-assignable) CP storage, or we'd have to rewrite all of storage allocation to know that there's an area that might have to be depopulated on demand at some point in the future, such that only truly pageable uses can be allocated out of it . The latter approach is certainly simpler, but also more restrictive, requiring pre-planning and definition of the area subject to later remova l. Quite a lot of work, and more than a few nasty complications, either way. - Bill Holder, z/VM Development, IBM
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Wed, 6 Aug 2008 08:50:31 -0700, Schuh, Richard <[EMAIL PROTECTED]> wrote : >How long of a period is 24 X 7 X 365? ... > >Regards, >Richard Schuh > > > > = === I always thought it meant "planned outages on Leap Days"! %-) - Bill Holder, z/VM Development, IBM
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Wed, Aug 6, 2008 at 7:16 PM, Schuh, Richard <[EMAIL PROTECTED]> wrote: > Just because it is widely used doesn't make it correct or accurate. I suppose the X is not the multiplication like in math, but a marketing operator. OT: We have a cigarette paper over here that uses the marketing slogan "3 times better: rolls better, sticks better, burns better" Clear abuse of mathematics. http://www.mascotte.nl/ Along those lines: "planned outages add up, unplanned outages multiply" -Rob
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Yes you are indeed correct. It made sense to ME when I wrote it! So, "Lucky to get PLANNED outages once a quarter" is what it should say. z/VM and the hardware have been darn near rock solid. We have had a bump or two in the road, but they have long been solved. From a virtualization and "massive" Linux on z environment capability/stability perspective, I give it three thumbs up. (One real, two virtual...) Jim Vincent On Wed, Aug 6, 2008 at 11:40 AM, Schuh, Richard <[EMAIL PROTECTED]> wrote: > That could be taken two ways. You are lucky if you allowed outages that > frequently or you are lucky if you get outages no more frequently than that > :-) Which is it? > > > Regards, > Richard Schuh >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
I would think that 24 X 7 X 52 would be more accurate - 24 hours/day X 7 days/week X 52 weeks/year. It yields a result in hours/year. The other yields (HOURS * DAYS**2) / (WEEKS * YEARS). Alternatively, 24 hours/day X 365 days/year gives a result in hours/year. Neither accounts for the fact that a year is slightly longer than either 365 days or 52 weeks. Just because it is widely used doesn't make it correct or accurate. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin > Sent: Wednesday, August 06, 2008 9:18 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > Gee, I don't know when the expression first started being > used, but I know I've been using it for at least two decades. :) > > 24 HOURS x 7 DAYS/WEEK x 365 DAYS/YEAR > > -MC > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard > Sent: Wednesday, August 06, 2008 11:51 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > > How long of a period is 24 X 7 X 365? Perhaps 365 weeks? 7 > years? 365 weeks? There is redundancy in the expression. I > would almost be willing to bet that nobody responding in the > affirmative to the question has had a Linux system up on > their zSeries for either 7 years or 365 weeks :-) > > Regards, > Richard Schuh > > > > > -Original Message- > > From: The IBM z/VM Operating System > > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin > > Sent: Wednesday, August 06, 2008 5:18 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > > > Yes, definitely. 24 x 7 x 365 > > > > -Mike > > > > -Original Message- > > From: The IBM z/VM Operating System > > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman > > Sent: Wednesday, August 06, 2008 2:06 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > > > Do people really have Linux systems that run 7 x 24? > > > > Alan Ackerman > > Alan (dot) Ackerman (at) Bank of America (dot) com > > >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Gee, I don't know when the expression first started being used, but I know I've been using it for at least two decades. :) 24 HOURS x 7 DAYS/WEEK x 365 DAYS/YEAR -MC -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, August 06, 2008 11:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY How long of a period is 24 X 7 X 365? Perhaps 365 weeks? 7 years? 365 weeks? There is redundancy in the expression. I would almost be willing to bet that nobody responding in the affirmative to the question has had a Linux system up on their zSeries for either 7 years or 365 weeks :-) Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin > Sent: Wednesday, August 06, 2008 5:18 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > Yes, definitely. 24 x 7 x 365 > > -Mike > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman > Sent: Wednesday, August 06, 2008 2:06 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > Do people really have Linux systems that run 7 x 24? > > Alan Ackerman > Alan (dot) Ackerman (at) Bank of America (dot) com >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
How long of a period is 24 X 7 X 365? Perhaps 365 weeks? 7 years? 365 weeks? There is redundancy in the expression. I would almost be willing to bet that nobody responding in the affirmative to the question has had a Linux system up on their zSeries for either 7 years or 365 weeks :-) Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin > Sent: Wednesday, August 06, 2008 5:18 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > Yes, definitely. 24 x 7 x 365 > > -Mike > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman > Sent: Wednesday, August 06, 2008 2:06 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > Do people really have Linux systems that run 7 x 24? > > Alan Ackerman > Alan (dot) Ackerman (at) Bank of America (dot) com >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
That could be taken two ways. You are lucky if you allowed outages that frequently or you are lucky if you get outages no more frequently than that :-) Which is it? Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of James Vincent Sent: Wednesday, August 06, 2008 4:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY And YES again here. We are _lucky_ if we get an outage once a quarter! Jim Vincent On Wed, Aug 6, 2008 at 6:11 AM, Mary Anne Matyaz <[EMAIL PROTECTED]> wrote: Do people really have Linux systems that run 7 x 24? YES. But I get an outage once a quarter. Usually.
Re: ADD VIRTUAL MEMORY DYNAMICALLY
I just retired a Marist installation had been running for just short of 8 years through 3 mainframes. It was a secondary DNS server, so it definitely ran 7x24x365. _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Pace Sent: Wednesday, August 06, 2008 8:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY Do people really have Linux systems that run 7 x 24? I have 5 currently that are 7 x 24. About to add a couple more. -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.
Re: ADD VIRTUAL MEMORY DYNAMICALLY
> > > > Do people really have Linux systems that run 7 x 24? > I have 5 currently that are 7 x 24. About to add a couple more. -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Do people really have Linux systems that run 7 x 24?
Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com
Alan,
You bet we do - more than one in fact
Bill Munson
Brown Brothers Harriman
z/VM System Programmer
201-418-7588
President MVMUA
http://www2.marist.edu/~mvmua/
Alan Ackerman <[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System
08/06/2008 02:06 AM
Please respond to
The IBM z/VM Operating System
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Tue, 5 Aug 2008 09:58:58 -0700, Schuh, Richard <[EMAIL PROTECTED]> wrote
:
>Yes, it can add, but not subtract without LPAR deactivation. Let me know
>when the ability to dynamically remove previously added storage is
>available, and I will be more enthusiastic.
>
>Regards,
>Richard Schuh
Deleting memory is a lot harder.
What if there are control blocks in there? You could use handles (pointer
s to pointers) but that is a
complete rewrite. If a control block can move, you cannot trust a registe
r to continue to point to
it. I think this would require a new instruction set to do the pointer to
pointer resolution directly.
Or you can fence off areas and say "no control blocks allowed in here". T
hat would increase the
complexity of operating systems, though. Such storage could only be used
to back up guest or
pageable operating system pages.
If you wanted to remove a block of memory, you would have to initiate a m
ass page-out to clear
the area. I'd rather not have to resolve the performance issues that migh
t occur.
Does z/OS do this?
I don't think the ability to remove memory is something I want IBM to spe
nd scarce z/VM
development dollars on.
Another thought:
The need to add memory may be an emergency situation. The need to remove
it again is not an
emergency and can be planned. How important avoiding an IML may be depend
s on whether you
really want to achieve 7 x 24 operation. 7 x 24 operation is going to cos
t you something --
including adequate capacity and memory.
There are other ways to achieve 7 x 24 operation. We don't run any system
s with true 7 x 24
requirements. We may run pairs of systems, or sysplexes of systems, but n
ot single systems.
Do people really have Linux systems that run 7 x 24?
Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com
*** IMPORTANT
NOTE* The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Wed, Aug 6, 2008 at 2:17 PM, Michael Coffin <[EMAIL PROTECTED]> wrote: > Yes, definitely. 24 x 7 x 365 That's from the IBM marketing material, IIRC :-) (unless you meant to retire after 7 years)
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Yes, definitely. 24 x 7 x 365 -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Wednesday, August 06, 2008 2:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY Do people really have Linux systems that run 7 x 24? Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: ADD VIRTUAL MEMORY DYNAMICALLY
And YES again here. We are _lucky_ if we get an outage once a quarter! Jim Vincent On Wed, Aug 6, 2008 at 6:11 AM, Mary Anne Matyaz <[EMAIL PROTECTED]>wrote: > > > Do people really have Linux systems that run 7 x 24? > > YES. But I get an outage once a quarter. Usually. >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Do people really have Linux systems that run 7 x 24? YES. But I get an outage once a quarter. Usually.
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Wed, Aug 6, 2008 at 8:06 AM, Alan Ackerman <[EMAIL PROTECTED]> wrote: > Deleting memory is a lot harder. Many delicate CP areas now also are in virtual memory as a result of the 2G relief, even though not all may be paged. It depends a lot on the granularity of the next level of mapping. When 90% of your in-use pages is virtual machine pages, you can probably find 16 MB worth of individual pages to give up. But evacuating pages at random in the hope to free an entire 16MB chunk is less attractive (I think some time ago pages under the bar would be freed like that). > Do people really have Linux systems that run 7 x 24? There are a lot of installations expecting their Linux guests on z/VM to be "always there" and the applications have been spoiled by hardware that was "almost always there" and tend to take that as their SLA, avoiding the need for redundancy and fail-over on the application level. You're very right that traditional installations approach this from another direction, understanding that (planned) outages for each component add up (multiply). They have applications designed to move and shift to achieve a higher availability than a single operating system. For example running the back-end with DB/2 on z/OS and the front-end with Linux on z/VM (where the front-end does not hold application data and is volatile). Once your applications can do that, the investment to transform a single system from "almost 7x24" to "full 7x24" is not justified anymore. Rob
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Tue, 5 Aug 2008 09:58:58 -0700, Schuh, Richard <[EMAIL PROTECTED]> wrote : >Yes, it can add, but not subtract without LPAR deactivation. Let me know >when the ability to dynamically remove previously added storage is >available, and I will be more enthusiastic. > >Regards, >Richard Schuh Deleting memory is a lot harder. What if there are control blocks in there? You could use handles (pointer s to pointers) but that is a complete rewrite. If a control block can move, you cannot trust a registe r to continue to point to it. I think this would require a new instruction set to do the pointer to pointer resolution directly. Or you can fence off areas and say "no control blocks allowed in here". T hat would increase the complexity of operating systems, though. Such storage could only be used to back up guest or pageable operating system pages. If you wanted to remove a block of memory, you would have to initiate a m ass page-out to clear the area. I'd rather not have to resolve the performance issues that migh t occur. Does z/OS do this? I don't think the ability to remove memory is something I want IBM to spe nd scarce z/VM development dollars on. Another thought: The need to add memory may be an emergency situation. The need to remove it again is not an emergency and can be planned. How important avoiding an IML may be depend s on whether you really want to achieve 7 x 24 operation. 7 x 24 operation is going to cos t you something -- including adequate capacity and memory. There are other ways to achieve 7 x 24 operation. We don't run any system s with true 7 x 24 requirements. We may run pairs of systems, or sysplexes of systems, but n ot single systems. Do people really have Linux systems that run 7 x 24? Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: ADD VIRTUAL MEMORY DYNAMICALLY
>>> On 8/5/2008 at 5:13 PM, in message <[EMAIL PROTECTED]>, "McKown, John" <[EMAIL PROTECTED]> wrote: -snip- > I don't know for a fact, but I'll bet that z/VM will not allow you to > have a single guest run on both an IFL and a CP. I'd bet that the > directory for the user will need designate either CP or IFL. That's pretty much what we were told at the T3 last week. CP will schedule Linux only IFLs, and the CP Directory entries for the Linux systems will need to say "use IFLs." So, the pricing is the same as before. If you have your Linux guests use CPs, then you pay for all the CPs. If only on IFLs, then you only pay for the number of IFLs. Mark Post
Re: ADD VIRTUAL MEMORY DYNAMICALLY
> -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch > Sent: Tuesday, August 05, 2008 4:08 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > [snip] > Anyway, I've been thinking about Linux pricing, that is, per > engine pricing. > Currently, we are being charged based on our single IFL > engine. And since the IFL engine was alone in its own LPAR, > that would be reasonable. But now, if we mix a 390 engine, > with the IFL engine in the same LPAR, would CP sechedule > Linux work on a 390 engine (assuming 390 engine wasn't too > busy)? Then, would we be in violation of our licensing > agreements? I sure wouldn't want to pay full engine price > for a 89 MIP, 390 engine . > > Tom Duerbusch > THD Consulting I don't know for a fact, but I'll bet that z/VM will not allow you to have a single guest run on both an IFL and a CP. I'd bet that the directory for the user will need designate either CP or IFL. If this were not true, then it might be possible to have z/OS in a "mixed" envirnoment where it IPLs on a CP, but runs some user code on an IFL. Some smart person MIGHT be able to hinky the dispatcher so that supervisor state code only runs on the CP. But I'm likely wrong. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Right. It is not a price difference, it is a resource difference. Less LPARs (down to 1) vs more LPARs: Less copies of VM running (along with all the service machines) a couple 3390 drives (still may need the same total number of paging/spool packs as well as SFS packs) Less real memory resident due to less copies of VM and service machines. (Letting VM manage the memory vs the fairly non-dynamic way LPARs obtain memory) Less real memory wasted that is needed for lessor used LPARs. Less consoles needed and needed to be monitored. Of course, there are good reasons for having LPARs. In this shop, we were forced into it due to having an IFL engine. I might go back to 1 LPAR for all 390 images and production zLinux images. Occasionally each LPAR starts paging, at different times (for somewhat valid reasons, sometimes not ). But then, no one notices enough to complain. The DS6800 can easily handle a few hundred page I/O per second without users complaining. Then things settle down to our normal couple page I/Os per second and life goes on. Nice that VM got back to being able to schedule based on engine type, like VM/SP did . (Yes, I assume that scheduling is much different/better then the old days of VM/SP.) Anyway, I've been thinking about Linux pricing, that is, per engine pricing. Currently, we are being charged based on our single IFL engine. And since the IFL engine was alone in its own LPAR, that would be reasonable. But now, if we mix a 390 engine, with the IFL engine in the same LPAR, would CP sechedule Linux work on a 390 engine (assuming 390 engine wasn't too busy)? Then, would we be in violation of our licensing agreements? I sure wouldn't want to pay full engine price for a 89 MIP, 390 engine . Tom Duerbusch THD Consulting Law of Dinner Table Attendance Cats must attend all meals when anything good is served. >>> Alan Altmark <[EMAIL PROTECTED]> 8/5/2008 3:35 PM >>> On Tuesday, 08/05/2008 at 04:14 EDT, Tom Duerbusch <[EMAIL PROTECTED]> wrote: > As now, we can mix and match 390 engines with IFLs (and other engine types) in > the same LPAR, it might be good to reduce the number of LPARs back to 1. You > gain the memory used by the other copies of VM, and you only need to add memory > to the LPAR when you buy more memory. > > I do know there are reasons for having multiple LPARs, but now with mixing > engine types, there is 1 less reason. > Everything under vswitch, and no hipersockets. Is that a performance benefit? Measure. Change. Measure. Compare. But I should mention that when running z/VM in a z/VM LPAR, the license fee is based on the total number of standard CPs and IFLs in the CEC. If you already had z/VM on the CP side and the IFL side, then there's no diff in price. Alan Altmark z/VM Development IBM Endicott
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Reduce numbers, maybe, but we will never get it down to one. There are requirements for separating production from development that will prevent it. There are, understandably so, very strict prohibitions against mixing the financial network and the testing and development network. Those prohibitions do not allow them to be connected to the same LPAR, even if they use physically separate OSAs (which they do), attached to different users (which, if it were allowed, would be the case). Furthermore, the SLAs are such that it is unwise to put the production Linux machines under the production z/VM system which supports a special TPF machine. Their outage window requirements, and therefore their SLAs, are incompatible. That leaves us with at least 3 LPARS plus whatever is needed for native TPF test systems. So far, I think that the largest native TPF configuration we have run is 3 LPARS, 2 on the same CEC as VM plus 1 on a different box. So our net gain would be the possible elimination of one LPAR. But even that will evaporate next year, when the second Linux LPAR becomes production. Do I hear some humming Perry Como's theme song in the background? Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch > Sent: Tuesday, August 05, 2008 1:13 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > As now, we can mix and match 390 engines with IFLs (and other > engine types) in the same LPAR, it might be good to reduce > the number of LPARs back to 1. You gain the memory used by > the other copies of VM, and you only need to add memory to > the LPAR when you buy more memory. > > I do know there are reasons for having multiple LPARs, but > now with mixing engine types, there is 1 less reason. > Everything under vswitch, and no hipersockets. Is that a > performance benefit? > > Now...how about basic mode again? > > Tom Duerbusch > THD Consulting > > >>> Mary Anne Matyaz <[EMAIL PROTECTED]> 8/5/2008 12:25 PM >>> > Uh, I've never seen Linux use LESS memory. It always wants > more. :) I'm happy with the ability to add memory. > MA > > On Tue, Aug 5, 2008 at 12:58 PM, Schuh, Richard > <[EMAIL PROTECTED]> wrote: > > > Yes, it can add, but not subtract without LPAR deactivation. Let me > > know when the ability to dynamically remove previously > added storage > > is available, and I will be more enthusiastic. > > > > Regards, > > Richard Schuh > > > > > > >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Tuesday, 08/05/2008 at 04:14 EDT, Tom Duerbusch <[EMAIL PROTECTED]> wrote: > As now, we can mix and match 390 engines with IFLs (and other engine types) in > the same LPAR, it might be good to reduce the number of LPARs back to 1. You > gain the memory used by the other copies of VM, and you only need to add memory > to the LPAR when you buy more memory. > > I do know there are reasons for having multiple LPARs, but now with mixing > engine types, there is 1 less reason. > Everything under vswitch, and no hipersockets. Is that a performance benefit? Measure. Change. Measure. Compare. But I should mention that when running z/VM in a z/VM LPAR, the license fee is based on the total number of standard CPs and IFLs in the CEC. If you already had z/VM on the CP side and the IFL side, then there's no diff in price. Alan Altmark z/VM Development IBM Endicott
Re: ADD VIRTUAL MEMORY DYNAMICALLY
As now, we can mix and match 390 engines with IFLs (and other engine types) in the same LPAR, it might be good to reduce the number of LPARs back to 1. You gain the memory used by the other copies of VM, and you only need to add memory to the LPAR when you buy more memory. I do know there are reasons for having multiple LPARs, but now with mixing engine types, there is 1 less reason. Everything under vswitch, and no hipersockets. Is that a performance benefit? Now...how about basic mode again? Tom Duerbusch THD Consulting >>> Mary Anne Matyaz <[EMAIL PROTECTED]> 8/5/2008 12:25 PM >>> Uh, I've never seen Linux use LESS memory. It always wants more. :) I'm happy with the ability to add memory. MA On Tue, Aug 5, 2008 at 12:58 PM, Schuh, Richard <[EMAIL PROTECTED]> wrote: > Yes, it can add, but not subtract without LPAR deactivation. Let me know > when the ability to dynamically remove previously added storage is > available, and I will be more enthusiastic. > > Regards, > Richard Schuh > > >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Ah, but our Linux workloads are in different LPARs, each running its own
z/VM system. Our main workload is on the system that requires the near
full-time availability of VM. It is the system that recently hosted 140
concurrent TPF guests ranging in size from a minimum of 900MB to a
maximum of 10GB. The future will see more of the sizes in the multiple
GB range as we convert systems to z/TPF. That is the VM that could
benefit from the ability to borrow storage from an unused LPAR during
peak loads and give it back in the off hours. As it is, we have two
LPARs that are reserved for native TPF testing. They are idle most of
the time and are rarely activated during the peak load periods on the VM
LPAR. They have a lot of memory that is as idle as are they.
Try as you might, you have not changed my opinion. And I am not trying
to change yours. Our circumstances, our problems, are different than
yours. I think the feature could be improved, and that I will not be
able to use it as announced. I think it is half of a solution to a
problem that we have encountered in the past and will encounter again.
Having the full solution would be very useful here. It would prevent the
need for memory upgrades by allowing us to share that memory that now
sits idle. There is a reason it sits idle, it prevents us from having to
deactivate our VM LPAR to reconfigure memory so that we can run the TPF
native LPARs. Right now, our only option is to have several GB of
storage reserved for the native LPARs.
Regards,
Richard Schuh
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mary Anne Matyaz
Sent: Tuesday, August 05, 2008 10:25 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY
Uh, I've never seen Linux use LESS memory. It always wants more.
:) I'm happy
with the ability to add memory.
MA
On Tue, Aug 5, 2008 at 12:58 PM, Schuh, Richard
<[EMAIL PROTECTED]> wrote:
Yes, it can add, but not subtract without LPAR
deactivation. Let me know
when the ability to dynamically remove previously added
storage is
available, and I will be more enthusiastic.
Regards,
Richard Schuh
> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:[EMAIL PROTECTED] On Behalf Of Bill
Holder
> Sent: Tuesday, August 05, 2008 9:09 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY
>
> On Tue, 29 Jul 2008 16:17:15 -0500, Bill Holder
> <[EMAIL PROTECTED]> wrot=
> e:
>
> >To address the question of adding Linux real memory
dynamically:
> >
> >The z/Linux support for dynamic addition of real
memory has been
> >provide=
> d to
> >the open source community fairly recently. (I don't
know the exact
> >date.=
> )
> >When that support becomes generally available is up
to the
> open source
> >community and the commercial distributors of Linux.
> >
> >There is no support for dynamically adding real
memory to
> z/VM itself
> >or=
>
> >dynamically increasing the "guest real" memory (that
is, "DEF STOR"
> >memory) for guest of z/VM in any announced release of
z/VM.
> >
> >- Bill Holder
> > z/VM Development, IBM
> >=
> ==
> ===
>
> As of this morning's announcement of z/VM 5.4.0, z/VM
support
> for dynamic addition of storage to z/VM itself, as
well as
> dynamic addition and removal of storage to/from z/VM
guests
> (if supported by the guest operating system) is now
announced.
>
> - Bill Holder
> z/VM Development, IBM
>
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Uh, I've never seen Linux use LESS memory. It always wants more. :) I'm happy with the ability to add memory. MA On Tue, Aug 5, 2008 at 12:58 PM, Schuh, Richard <[EMAIL PROTECTED]> wrote: > Yes, it can add, but not subtract without LPAR deactivation. Let me know > when the ability to dynamically remove previously added storage is > available, and I will be more enthusiastic. > > Regards, > Richard Schuh > > > > > -Original Message- > > From: The IBM z/VM Operating System > > [mailto:[EMAIL PROTECTED] On Behalf Of Bill Holder > > Sent: Tuesday, August 05, 2008 9:09 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > > > On Tue, 29 Jul 2008 16:17:15 -0500, Bill Holder > > <[EMAIL PROTECTED]> wrot= > > e: > > > > >To address the question of adding Linux real memory dynamically: > > > > > >The z/Linux support for dynamic addition of real memory has been > > >provide= > > d to > > >the open source community fairly recently. (I don't know the exact > > >date.= > > ) > > >When that support becomes generally available is up to the > > open source > > >community and the commercial distributors of Linux. > > > > > >There is no support for dynamically adding real memory to > > z/VM itself > > >or= > > > > >dynamically increasing the "guest real" memory (that is, "DEF STOR" > > >memory) for guest of z/VM in any announced release of z/VM. > > > > > >- Bill Holder > > > z/VM Development, IBM > > >= > > == > > === > > > > As of this morning's announcement of z/VM 5.4.0, z/VM support > > for dynamic addition of storage to z/VM itself, as well as > > dynamic addition and removal of storage to/from z/VM guests > > (if supported by the guest operating system) is now announced. > > > > - Bill Holder > > z/VM Development, IBM > > >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Yes, it can add, but not subtract without LPAR deactivation. Let me know when the ability to dynamically remove previously added storage is available, and I will be more enthusiastic. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Bill Holder > Sent: Tuesday, August 05, 2008 9:09 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > On Tue, 29 Jul 2008 16:17:15 -0500, Bill Holder > <[EMAIL PROTECTED]> wrot= > e: > > >To address the question of adding Linux real memory dynamically: > > > >The z/Linux support for dynamic addition of real memory has been > >provide= > d to > >the open source community fairly recently. (I don't know the exact > >date.= > ) > >When that support becomes generally available is up to the > open source > >community and the commercial distributors of Linux. > > > >There is no support for dynamically adding real memory to > z/VM itself > >or= > > >dynamically increasing the "guest real" memory (that is, "DEF STOR" > >memory) for guest of z/VM in any announced release of z/VM. > > > >- Bill Holder > > z/VM Development, IBM > >= > == > === > > As of this morning's announcement of z/VM 5.4.0, z/VM support > for dynamic addition of storage to z/VM itself, as well as > dynamic addition and removal of storage to/from z/VM guests > (if supported by the guest operating system) is now announced. > > - Bill Holder > z/VM Development, IBM >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Tue, 29 Jul 2008 16:17:15 -0500, Bill Holder <[EMAIL PROTECTED]> wrot e: >To address the question of adding Linux real memory dynamically: > >The z/Linux support for dynamic addition of real memory has been provide d to >the open source community fairly recently. (I don't know the exact date. ) >When that support becomes generally available is up to the open source >community and the commercial distributors of Linux. > >There is no support for dynamically adding real memory to z/VM itself or >dynamically increasing the "guest real" memory (that is, "DEF STOR" >memory) for guest of z/VM in any announced release of z/VM. > >- Bill Holder > z/VM Development, IBM > = === As of this morning's announcement of z/VM 5.4.0, z/VM support for dynamic addition of storage to z/VM itself, as well as dynamic addition and removal of storage to/from z/VM guests (if supported by the guest operating system) is now announced. - Bill Holder z/VM Development, IBM
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Don't groan. You gave him the incentive :-) Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Thursday, July 31, 2008 2:37 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > On Thursday, 07/31/2008 at 04:42 EDT, Brian Nielsen > <[EMAIL PROTECTED]> wrote: > > I'm virtually certain that you really believe in the > absolute truth of > > that, and as you might have guessed, so do I. If memory > serves me, I > > havn't had a Hostess cupcake in a long time - I was last at > the store > ages > > ago. > > > > Alan Altmark > z/VM Development > IBM Endicott >
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Thursday, 07/31/2008 at 04:42 EDT, Brian Nielsen <[EMAIL PROTECTED]> wrote: > I'm virtually certain that you really believe in the absolute truth of > that, and as you might have guessed, so do I. If memory serves me, I > havn't had a Hostess cupcake in a long time - I was last at the store ages > ago. Alan Altmark z/VM Development IBM Endicott
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Thu, 31 Jul 2008 15:52:52 -0400, Alan Altmark <[EMAIL PROTECTED] > wrote: >On Monday, 07/28/2008 at 03:55 EDT, "McKown, John" ><[EMAIL PROTECTED]> wrote: >> Hum, perhaps we need a code phrase to distinguish VM "virtual memory" , >which >> is guest "real memory" from guest "virtual memory"? > >These terms already exist. > > Guest virtual >Guest real > Guest absolute > Host virtual > Host real >Host absolute > > >In z/VM, guest memory (all 3 types) resides in host virtual. In most >cases it is not really necessary to distinguish between absolute and rea l. > What everyone thinks of when they say "real" is actually "absolute". I'm virtually certain that you really believe in the absolute truth of that, and as you might have guessed, so do I. If memory serves me, I havn't had a Hostess cupcake in a long time - I was last at the store age s ago. Brian Nielsen (who couldn't resist the urge. sorry.)
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Monday, 07/28/2008 at 03:55 EDT, "McKown, John" <[EMAIL PROTECTED]> wrote: > Hum, perhaps we need a code phrase to distinguish VM "virtual memory", which > is guest "real memory" from guest "virtual memory"? These terms already exist. Guest virtual Guest real Guest absolute Host virtual Host real Host absolute In z/VM, guest memory (all 3 types) resides in host virtual. In most cases it is not really necessary to distinguish between absolute and real. What everyone thinks of when they say "real" is actually "absolute". Alan Altmark z/VM Development IBM Endicott
Re: ADD VIRTUAL MEMORY DYNAMICALLY
To address the question of adding Linux real memory dynamically: The z/Linux support for dynamic addition of real memory has been provided to the open source community fairly recently. (I don't know the exact date.) When that support becomes generally available is up to the open source community and the commercial distributors of Linux. There is no support for dynamically adding real memory to z/VM itself or dynamically increasing the "guest real" memory (that is, "DEF STOR" memory) for guest of z/VM in any announced release of z/VM. - Bill Holder z/VM Development, IBM
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Ah! Richard wins. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, July 28, 2008 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY Thanks that is what I thought! Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Monday, July 28, 2008 3:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY No. Redefining virtual memory causes a virtual system reset. It takes an IPl after that. You can update the directory to allow additional, but you cannot redefine the virtual storage of a running machine without causing the reset. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, July 28, 2008 12:40 PM To: IBMVM@LISTSERV.UARK.EDU Subject: ADD VIRTUAL MEMORY DYNAMICALLY Hi I have a Linux server running now that is in need of more VIRTUAL MEMEORY. Is there a way that I can dynamically allocate more memory to this guest without bring it down? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Thanks that is what I thought! Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Monday, July 28, 2008 3:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY No. Redefining virtual memory causes a virtual system reset. It takes an IPl after that. You can update the directory to allow additional, but you cannot redefine the virtual storage of a running machine without causing the reset. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, July 28, 2008 12:40 PM To: IBMVM@LISTSERV.UARK.EDU Subject: ADD VIRTUAL MEMORY DYNAMICALLY Hi I have a Linux server running now that is in need of more VIRTUAL MEMEORY. Is there a way that I can dynamically allocate more memory to this guest without bring it down? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Very true. You are likely correct that the OP needs more VM "def
storage" memory because the guest is doing too much paging to its paging
subsystem. Hum, perhaps we need a code phrase to distinguish VM "virtual
memory", which is guest "real memory" from guest "virtual memory"?
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Monday, July 28, 2008 2:51 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY
The question was on the VM list. I may have mistaken it for a
question about VM, not Linux ;-)
Regards,
Richard Schuh
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of McKown, John
Sent: Monday, July 28, 2008 12:47 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY
Depends on what the OP means by "virtual memory". If he
means more VM "real" (to the guest), then you're correct. But if he
needs more Linux paging memory, then a VDISK, mkswap, swapon should
help.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains
confidential information intended for a specific individual and purpose,
and its content is protected by law. If you are not the intended
recipient, you should delete this message and are hereby notified that
any disclosure, copying, or distribution of this transmission, or taking
any action based on it, is strictly prohibited.
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Monday, July 28, 2008 2:43 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY
No. Redefining virtual memory causes a virtual
system reset. It takes an IPl after that. You can update the directory
to allow additional, but you cannot redefine the virtual storage of a
running machine without causing the reset.
Regards,
Richard Schuh
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR)
(CTR)
Sent: Monday, July 28, 2008 12:40 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: ADD VIRTUAL MEMORY DYNAMICALLY
Hi
I have a Linux server running now that
is in need of more VIRTUAL MEMEORY. Is there a way that I can
dynamically allocate more memory to this guest without bring it down?
Thank You,
Terry Martin
Lockheed Martin - Information Technology
z/OS & z/VM Systems - Performance and
Tuning
Cell - 443 632-4191
Work - 410 786-0386
[EMAIL PROTECTED]
Re: ADD VIRTUAL MEMORY DYNAMICALLY
The question was on the VM list. I may have mistaken it for a question
about VM, not Linux ;-)
Regards,
Richard Schuh
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of McKown, John
Sent: Monday, July 28, 2008 12:47 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY
Depends on what the OP means by "virtual memory". If he means
more VM "real" (to the guest), then you're correct. But if he needs more
Linux paging memory, then a VDISK, mkswap, swapon should help.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Monday, July 28, 2008 2:43 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY
No. Redefining virtual memory causes a virtual system
reset. It takes an IPl after that. You can update the directory to allow
additional, but you cannot redefine the virtual storage of a running
machine without causing the reset.
Regards,
Richard Schuh
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR)
(CTR)
Sent: Monday, July 28, 2008 12:40 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: ADD VIRTUAL MEMORY DYNAMICALLY
Hi
I have a Linux server running now that is in
need of more VIRTUAL MEMEORY. Is there a way that I can dynamically
allocate more memory to this guest without bring it down?
Thank You,
Terry Martin
Lockheed Martin - Information Technology
z/OS & z/VM Systems - Performance and Tuning
Cell - 443 632-4191
Work - 410 786-0386
[EMAIL PROTECTED]
Re: ADD VIRTUAL MEMORY DYNAMICALLY
Depends on what the OP means by "virtual memory". If he means more VM
"real" (to the guest), then you're correct. But if he needs more Linux
paging memory, then a VDISK, mkswap, swapon should help.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Monday, July 28, 2008 2:43 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY
No. Redefining virtual memory causes a virtual system reset. It
takes an IPl after that. You can update the directory to allow
additional, but you cannot redefine the virtual storage of a running
machine without causing the reset.
Regards,
Richard Schuh
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR)
(CTR)
Sent: Monday, July 28, 2008 12:40 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: ADD VIRTUAL MEMORY DYNAMICALLY
Hi
I have a Linux server running now that is in need of
more VIRTUAL MEMEORY. Is there a way that I can dynamically allocate
more memory to this guest without bring it down?
Thank You,
Terry Martin
Lockheed Martin - Information Technology
z/OS & z/VM Systems - Performance and Tuning
Cell - 443 632-4191
Work - 410 786-0386
[EMAIL PROTECTED]
Re: ADD VIRTUAL MEMORY DYNAMICALLY
On Jul 28, 2008, at 2:43 PM, Schuh, Richard wrote: No. Redefining virtual memory causes a virtual system reset. It takes an IPl after that. You can update the directory to allow additional, but you cannot redefine the virtual storage of a running machine without causing the reset. Well, not quite true. You could add more swap. And if you added swap-on-VDISK, it'd really live in memory (assuming no memory pressure on the Linux guest). So, define VDISK to the machine at some address. Bring it online through the /sys/bus/ccw interface. mkswap to format it. swapon /dev/ dasdt1 (or whatever), and you should have a machine able to swap to your new VFB-512 disk. Adam
Re: ADD VIRTUAL MEMORY DYNAMICALLY
I may not be understanding what you need, but I thnk you could format a
new Linux swap disk (say a VDISK) then add it to the Linux system's
paging configuration using a "mkswap" followed by a "swapon".
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR)
(CTR)
Sent: Monday, July 28, 2008 2:40 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: ADD VIRTUAL MEMORY DYNAMICALLY
Hi
I have a Linux server running now that is in need of more
VIRTUAL MEMEORY. Is there a way that I can dynamically allocate more
memory to this guest without bring it down?
Thank You,
Terry Martin
Lockheed Martin - Information Technology
z/OS & z/VM Systems - Performance and Tuning
Cell - 443 632-4191
Work - 410 786-0386
[EMAIL PROTECTED]
Re: ADD VIRTUAL MEMORY DYNAMICALLY
No. Redefining virtual memory causes a virtual system reset. It takes an IPl after that. You can update the directory to allow additional, but you cannot redefine the virtual storage of a running machine without causing the reset. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, July 28, 2008 12:40 PM To: IBMVM@LISTSERV.UARK.EDU Subject: ADD VIRTUAL MEMORY DYNAMICALLY Hi I have a Linux server running now that is in need of more VIRTUAL MEMEORY. Is there a way that I can dynamically allocate more memory to this guest without bring it down? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
ADD VIRTUAL MEMORY DYNAMICALLY
Hi I have a Linux server running now that is in need of more VIRTUAL MEMEORY. Is there a way that I can dynamically allocate more memory to this guest without bring it down? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
Re: virtual memory
In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes: >> Was there an acronym/initialism for this COMMON area? My memory of >> doing junior-level systems work on MVS systems is telling me that >> there was one, but not what. ? > >"common segment" ... having started out as a 1mbyte "shared" segment >in every address space. > >the hardware table look-aside buffers (TLBs) were STO (virtual address >space) associative. the result was that there were unique entries for >the same common segment entries from different virtual address spaces. > >in the early 80s, some of the high-end hardware started adding special >TLB treatment for the MVS "common segment" ... so that there would >only be one set of TLB entries for MVS common segment areas across all common segment area, common segment area Aha! "CSA" is the acronym/initialism I was trying to remember. (A quick Google search turns up several other alleged expansions -- "common system area", "common storage area", "common service area" -- but maybe we shouldn't worry about that.) Thanks. >MVS address spaces. However, this references a "bug" when MVS was >running as a virtual guest ... and a temporary fix ... pending >availability of MVS APAR. > >Date: 18 February 1983, 12:30:13 EST >From: > >Hi - the 'official' fix to the STBVR 0Cx abend problem is MVS APAR/ >PTF OZ67587. I don't know if it's available yet. In the meantime, >the zap works just fine. > >I'll send the zap following this note. > >//x JOB (6007,X003),,MSGLEVEL=1,MSGCLASS=O,CLASS=B, >// REGION=1024K,NOTIFY=PREISM >//ZAP EXEC PGM=AMASPZAP >//SYSPRINT DD SYSOUT=* >//SYSLIB DD DSN=SYS1.NUCLEUS,DISP=SHR,UNIT=3330,VOL=SER=D00126 >** >** FOR VM MVS GUEST, STBVR, TURN OFF USE OF COMMON SEGMENTS >** > NAME IEAVNPX1 IEAVNPX1 > VER 0DA2 96026003OI SGTCB=1 > REP 0DA2 4700NOP > VER 0DCE 96026003OI SGTCB=1 > REP 0DCE 4700NOP >// -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
Re: virtual memory
[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes: > Was there an acronym/initialism for this COMMON area? My memory of > doing junior-level systems work on MVS systems is telling me that > there was one, but not what. ? "common segment" ... having started out as a 1mbyte "shared" segment in every address space. the hardware table look-aside buffers (TLBs) were STO (virtual address space) associative. the result was that there were unique entries for the same common segment entries from different virtual address spaces. in the early 80s, some of the high-end hardware started adding special TLB treatment for the MVS "common segment" ... so that there would only be one set of TLB entries for MVS common segment areas across all MVS address spaces. However, this references a "bug" when MVS was running as a virtual guest ... and a temporary fix ... pending availability of MVS APAR. Date: 18 February 1983, 12:30:13 EST From: Hi - the 'official' fix to the STBVR 0Cx abend problem is MVS APAR/ PTF OZ67587. I don't know if it's available yet. In the meantime, the zap works just fine. I'll send the zap following this note. //x JOB (6007,X003),,MSGLEVEL=1,MSGCLASS=O,CLASS=B, // REGION=1024K,NOTIFY=PREISM //ZAP EXEC PGM=AMASPZAP //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SYS1.NUCLEUS,DISP=SHR,UNIT=3330,VOL=SER=D00126 ** ** FOR VM MVS GUEST, STBVR, TURN OFF USE OF COMMON SEGMENTS ** NAME IEAVNPX1 IEAVNPX1 VER 0DA2 96026003OI SGTCB=1 REP 0DA2 4700NOP VER 0DCE 96026003OI SGTCB=1 REP 0DCE 4700NOP // -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Re: virtual memory
II(RC, you are referring to the Link Pack Area (LPA). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 11:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject:Re: virtual memory In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote: [ snip ] >SVS evolved into MVS ... there was a separate address space for every >application. However, because of the heavy pointer passing paradigm, >the "MVS" kernel actually occupied 8mbytes of every application >16mbyte virtual address space. There was some additional hacks >required. There were some number of things called subsystems that were >part of most operational environments. They existed outside of the >kernel (in their own virtual address space) ... but in the MVT & SVS >worlds, other applications were in the habit of directly calling these >subsystem functions using pointer passing paradigm ... which required >the subsystems (which now were in separate address space) to directly >access the calling application's parameters in the application's >virtual address space. > >The initial solution was something called a "COMMON" segment, a (again >initially) 1mbyte area of every virtual address space where >applications could stuff parameter values that they needed to be >accessed by called subsystems, resident in other address spaces. Over >time, as customer installations added a large variety of subsystems, >it was unusual to find the COMMON segment taking up five megabytes. >While these were MVS systems, with a unique 16mbyte virtual address >space for every application, the kernel image was taking 8mbytes out >of every virtual address space, and with a five megabyte COMMON area, >that would leave a maximum of 3mbytes for application use (out of a >16mbyte virtual address space). (Just now working my way through this thread; great stuff ) Was there an acronym/initialism for this COMMON area? My memory of doing junior-level systems work on MVS systems is telling me that there was one, but not what. ? [ snip ] -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
Re: virtual memory
In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote: [ snip ] >SVS evolved into MVS ... there was a separate address space for every >application. However, because of the heavy pointer passing paradigm, >the "MVS" kernel actually occupied 8mbytes of every application >16mbyte virtual address space. There was some additional hacks >required. There were some number of things called subsystems that were >part of most operational environments. They existed outside of the >kernel (in their own virtual address space) ... but in the MVT & SVS >worlds, other applications were in the habit of directly calling these >subsystem functions using pointer passing paradigm ... which required >the subsystems (which now were in separate address space) to directly >access the calling application's parameters in the application's >virtual address space. > >The initial solution was something called a "COMMON" segment, a (again >initially) 1mbyte area of every virtual address space where >applications could stuff parameter values that they needed to be >accessed by called subsystems, resident in other address spaces. Over >time, as customer installations added a large variety of subsystems, >it was unusual to find the COMMON segment taking up five megabytes. >While these were MVS systems, with a unique 16mbyte virtual address >space for every application, the kernel image was taking 8mbytes out >of every virtual address space, and with a five megabyte COMMON area, >that would leave a maximum of 3mbytes for application use (out of a >16mbyte virtual address space). (Just now working my way through this thread; great stuff ) Was there an acronym/initialism for this COMMON area? My memory of doing junior-level systems work on MVS systems is telling me that there was one, but not what. ? [ snip ] -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
Re: virtual memory
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > TROUT has never treated SIE as "just another assist." SIE has been a > basic part of our machine's design since the beginning. In fact, we > have chosen to put many functions into hardware instead of microcode > to pick up significant performance gains. For example, the 3081 takes > a significant amount of time to do certain types of guest-to-host > address translation because it does them in microcode, while TROUT > does them completely in hardware. re: http://www.garlic.com/~lynn/2006j.html#27 virtual memory "811" (named after 11/78 publication date on the architecture documents) or 3081 was considered somewhat of a 155/158 follow-on machine ... being much more of a m'coded machine. "TROUT" or 3090 was considered somewhat of a 165/168 follow-on machine ... being much more of a hardwired machine. these were the days of processors getting bigger and bigger with much more effort being put into more processors in SMP configuration. they had created two positions, one in charge of "tightly-coupled" architecuture (SMP) and one in charge of "loosely-coupled" architecture (clusters). my wife got con'ed into taking the job in pok in charge of loosed-coupled architecture. she didn't last long ... while there, she did do done peer-coupled shared data architecture http://www.garlic.com/~lynn/subtopic.html#shareddata which didn't see much uptake until sysplex ... except for the ims group doing ims hot-standby. part of the problem was she was fighting frequently with the communication's group, who wanted SNA/VTAM to be in charge of any signals leaving a processor complex (even those directly to another processor). one example was trouter/3088 ... she fought hard for hardware enhancements for full-duplex operation. there had been a previous "channel-to-channel" hardware which was half-duplex direct channel/bus communication between two processor complexes. 3088 enhanced this to provide connectivity to up to eight different processor complexes. sna was essentially a dumb terminal controller infrastructure. their reference to it as a "network" required other people in the organization to migrate to using the term "peer-to-peer network" to differentiate from the sna variety. of course, earlier, in the time-frame that sna was just starting out ... she had also co-authored a peer-to-peer networking architecture with Burt Moldow ... which was somewhat viewed as threatening to sna ... misc. past posts mentioning awp39: http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment http://www.garlic.com/~lynn/2004p.html#31 IBM 3705 and UC.5 http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS http://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ? http://www.garlic.com/~lynn/2005u.html#23 Channel Distances http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe anyway, in the trotter/3088 time-frame ... san jose had done a prototype vm/cluster implementation using a modified trotter/3088 with full-duplex protocols. however, before it was allowed to ship, they had to convert it to san operation. one of the cluster example was to fully "resynch" cluster operation of all the processors ... with took under a second using full-duplex protocols on the 3088 ... but the same operation took on the order of a minute using sna protocols and a half-duplex paradigm. we ran afoul again later with 3-tier architecture http://www.garlic.com/~lynn/subtopic.html#3tier this was in the time-frame that the communications group was out pushing SAA ... a lot of which was an attempt to revert back to terminal emulation paradigm http://www.garlic.com/~lynn/subnetwork.html#emulation from that of client/server. we had come up with 3-tier architecture and was out pitching it to customer executives ... and the same time they were trying to revert 2-tier architecture back to dumb terminal emulation. then we did ha/cmp product http://www.garlic.com/~lynn/subtopic.html#hacmp minor reference http://www.garlic.com/~lynn/95.html#13 which didn't make a lot of them happy either. -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Re: virtual memory
"Memory is like an orgasm - it's better when you don't have to fake it." "You can't fake what you don't have". "In this business, you can't fake what you don't have" "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?" -- Seymour Cray Scene: 1979 Cray Research, Inc. Annual Meeting Lutherin Brotherhood Building, Minneapolis, Mn. Q & A period, after the address by the Officers of the Company, Q: "Mr. Cray, ... Since you seem to have implemented almost all of the current schemes published in the scientific press on improving performance in your systems, I was wondering why you didn't also provide for virtual memeory?" A: From Mr. Cray: "Well as you know, over the years I have provided the largest physical memories available for use. The addition of a "virtual memory" scheme would have added another level of hardware and hardware addressing delays in accessing code and data. I believe that it's better to spend the resource providing for a larger overall memory system for the programmer. ... Historically, this is what the programmers have preferred." --
Re: virtual memory
IBM OS Timeline? http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline? http://www.garlic.com/~lynn/2001l.html#36 History http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?) http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post) http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems http://www.garlic.com/~lynn/2002n.html#62 PLX http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's http://www.garlic.com/~lynn/2004m.html#16 computer industry scenairo before the invention of the PC? http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect http://www.garlic.com/~lynn/2004n.html#54 CKD Disks? http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey http://www.garlic.com/~lynn/2005b.html#50 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line http://www.garlic.com/~lynn/2005p.html#18 address space http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory? http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory? http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT http://www.garlic.com/~lynn/2006i.html#33 virtual memory http://www.garlic.com/~lynn/2006j.html#5 virtual memory -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
{SPAM?} Re: virtual memory
In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] writes: Just for clarification: I don't think I ever knew how TOPS-10 did the stuff at this level. I do remember discussions about it all but I understood 0% of what the guys talked about. I no longer can recall what was said, let alone the order. ISTM that DECUS had some sessions about all this stuff. Is any of those session writeups available? /BAH
Virtual memory implementation in S/370
(I wrote) >>VAX uses a two level system where page tables are paged. >>There is kernel space, which isn't paged and holds the first >>level tables referencing pagable second level tables. >>z/Archtecture has three levels. (someone else wrote) > Actually, z/Architecture has 5 levels. So far, > the existed hardware only uses 3 of them. I thought of that right after sending it. Above the addressing within a page, it is, more or less, 10 bits per level. (For S/370, one could consider the 32 bit addressing for the 360/67, which is fairly similar.) For an undergrad operating system course I did a report comparing S/370 and VAX virtual memory systems (around the time when VAX was new). I remember finding more similarities than differences, especially both using the two level system. So for 64 bit addressing of 4K pages, (64-12)/10 is about five. Allowing the hardware to use three until more addressing bits are needed is a nice feature. -- glen
Re: virtual memory
[EMAIL PROTECTED] writes: > Then a subset of those categories would have to be code > and data, with the rare exception where code is data > (writable code segment which god never meant happen). > > I suppose there would also have to be special handling > of data pages that were suddenly changed to code. > > Comments on the discussion: > > 1. An OS did not need VM to do relocation. Example: KA10. > 2. Do not confuse paging hardware with virtual memory. > They are different. The reason this confusion happens > is because both were usually done during the same > major version OS release.If your new CPU has paging > hardware, you might as well schedule your VM project > at the same time. You might as well subject the customer > to both pains all at the same time. It was like > pulling a tooth: yank it and get it over with or tweak > it and have years of long drawn annoying pain in the > nethers. i've described two instances where there was special case processing ... and both instances resulted in non-optimal implementations ... * one was the initial morph from cp67 to vm370 where they had actual lists of pages for the scanning/reset/replacement selection and "shared" pages were treated specially ... not based on reference bits * the other was the initial morph from mvt to os/vs2 where they would bias the replacement selection for non-changed pages before changed pages post including description of the above two scenarios http://www.garlic.com/~lynn/2006i.html#43 virtual memory i had arguments with both groups over the details and they went ahead and did it anyway (which, in both cases, got corrected much later ... the os/vs2 they had to do the correction themselves, the vm370 shared pages, i was able to correct in the release of the resource manager). i had also done a paging, non-virtual memory thing originally as an undergraduate in the 60s for cp67 ... but it was never picked up in the product until the morph of cp67 to vm370 where it was used. the issue was the kernel code ran real mode, w/o hardware translate turned on. all its addressing was based on real addresses. when dealing with addresses from virtual address space ... it used the LRA (load real address) instruction that translated from virtual to real. the issue was that the real kernel size was continuing to grow as more and more features were being added. this was starting to impact the number of pages left over for virtual address paging. recent post in this thread making mention of measure of "pageable pages" (after fixed kernel requirements): http://www.garlic.com/~lynn/2006i.html#36 virtual memory http://www.garlic.com/~lynn/2006j.html#2 virtual memory so i created a dummy set of tables for the "kernel" address space ... and partitioned some low-useage kernel routines (various kinds of commands, etc) into real, 4k "chunks". I positioned all these real chunks at the high end of the kernel. When there were calls to addresses above the "pageable" line ... the call processing ... instead of directly transfering would run the address thru the dummy table to see if the chunk was actually resident. if it was resident, then the call would be made to the translated address location ... running w/o virtual memory turned on. if the 4k chunk was indicated as not resident, the paging routine was called to bring it into storage before transferring to the "real" address. during the call, the page fixing and lock ... that CCWTRANS for performing virtual i/o ... was used for preventing the page for be selected from removal from real storage. the count was decremented at the return. otherwise these "pageable" kernel pages could be selected for replacement just like any other page. some recent mentions of CCWTRANS http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory? http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory? http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT http://www.garlic.com/~lynn/2006i.html#33 virtual memory this feature never shipped as part of the cp67 kernel, but was picked up as part of the initial morph of cp67 to vm370. Later for the resource manager, i also created a (2nd) small dummy set of tables for every virtual address space that was used for administrative writing of tables to disk. tables were collected into page-aligned 4k real chunks and the page I/O infrastructure was used for moving the tables to/from disk (in a manner similar to how i had done the original pageable kernel implementation) previous description of "paging" SWAPTABLEs. http://www.garlic.com/~lynn/2006i.html#24 Virtual memory implementation in S/370 in the initial morph of cp67->vm370, some of cms was re-orged to take advantage of the 370 shared segment
{SPAM?} Re: virtual memory
In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote: >they were also claiming that they were doing a least recently used >replacement stragegy. however, their performance group did some simple >modeling and found that if they choose non-changed least recently used >pages ... before choosing changed least recently used pages ... that >the service time to handle the replacement was drastically reduced. a >non-changed page already had an exact duplicate out on disk ... and >therefor replacement processing could simply discard the copy in >virtual memory and make the real memory location available. Right. All you had to was zero the word, or half word, or bit, that pointed at the index of the page table. But, now you have the decision of when does the data within that page get zeroed when it is placed into the next address space usage list. I don't think it matters as long as they're all done on the same side of usage. >a >"changed" page selected for replacement, first had to be written to >disk before the real memory location was available. first attempting >to select non-changed pages for replacement significantly reduced the >service time and processing. I argued that such approach basically >perturbed and violated any claim as to approximating least recently >used replacement strategy. they did it any way. > >so os/vs2 svs eventually morphed into os/vs2 mvs ... and then they >shortened the name to just calling it mvs. customers had been using it >for some number of years ... it was coming up in 1980 ... and somebody >discovered that high-useage, shared executable images (i.e. same >executable image appearing in lots of different virtual address spaces >and being executed by lots of different applications) were being >selected for replacement before low-useage application data pages. The >high-useage, shared executable images were "read-only" ... aka they >were never modified and/or changed. The low-useage application data >areas were constantly being changed. As a result, the high-useage >(execution, shared) pages were being selected for replacement before >low-useage application data pages. They didn't keep a count of how many were sharing the code? This means that user data pages had the same priority as code? One would assume that all user data pages would have be written out. > >in much the same way that the vm370 page list management was >constantly and significantly changing the order that pages were >examined for replacement ... invalidating basic premise of least >recently used replacement stragegies ... the os/vs2 (svs and mvs) was >also creating an ordering different than based on purely use ... also >invalidating basic premise of least recently used replacement >strategies. Was there a difference between exec pages and user pages? Then a subset of those categories would have to be code and data, with the rare exception where code is data (writable code segment which god never meant happen). I suppose there would also have to be special handling of data pages that were suddenly changed to code. Comments on the discussion: 1. An OS did not need VM to do relocation. Example: KA10. 2. Do not confuse paging hardware with virtual memory. They are different. The reason this confusion happens is because both were usually done during the same major version OS release.If your new CPU has paging hardware, you might as well schedule your VM project at the same time. You might as well subject the customer to both pains all at the same time. It was like pulling a tooth: yank it and get it over with or tweak it and have years of long drawn annoying pain in the nethers. /BAH
Re: virtual memory
"Eric P." <[EMAIL PROTECTED]> writes: > VMS and WNT use Second Chance Fifo, which has very different behavior > to strict Fifo, and is reputed to have the same behavior as WSClock. > VMS also has an option for a third chance - I don't know if WNT > also has that. This gives them all the control advantages that > local working sets allow with the same paging statistics as global. > > In second chance fifo, pages removed from a local working set are > tossed into a global Valid list to become a candidate for recycling. > If referenced again quickly the page is pulled page into the local > working set for almost no cost. This is essentially the same as > the WSClock and its referenced bits. > > In 3rd chance, VMS allows a page to make 2 trips through the working > set list. After the first trip a flag is set on the working set entry > it goes to the tail of the list and the PTE's valid flag is cleared. > If it gets touched again then the handler just enables the PTE. > When it gets to the head of the list again the PTE is checked to > see if it was referenced. If is was, it cycles again, otherwise > it goes into the global Valid list. [1] as mentioned in the previous post http://www.garlic.com/~lynn/2006i.html#22 virtual memory http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370 http://www.garlic.com/~lynn/2006i.html#24 Virtual memory implementation in S/370 http://www.garlic.com/~lynn/2006i.html#28 virtual memory http://www.garlic.com/~lynn/2006i.html#30 virtual memory http://www.garlic.com/~lynn/2006i.html#31 virtual memory http://www.garlic.com/~lynn/2006i.html#32 virtual memory http://www.garlic.com/~lynn/2006i.html#33 virtual memory http://www.garlic.com/~lynn/2006i.html#36 virtual memory http://www.garlic.com/~lynn/2006i.html#37 virtual memory http://www.garlic.com/~lynn/2006i.html#38 virtual memory http://www.garlic.com/~lynn/2006i.html#39 virtual memory http://www.garlic.com/~lynn/2006i.html#40 virtual memory http://www.garlic.com/~lynn/2006i.html#41 virtual memory http://www.garlic.com/~lynn/2006i.html#42 virtual memory some of the work that i had done in the 60s as an undergraduate for cp67 ... had been dropped in the morph from cp67 to vm370. i was able to rectify that with the resource manager released 11may1976. the cp67 "clock" scanned pages by their real storage address. basically the idea behind a "clock" reset and testing the reference bit is that the time it takes to cycle completely around all virtual pages represents approximately the same interval between the resetting and testing for all pages. one of the advantages of clock type implementation that i had done in the 60s was that it had some interesting dynamic adaptive stuff. if there weren't enuf pages, the replacement algorithm would be called more frequently ... causing it to cycle through more pages faster. as it did the cycle quicker ... there was shortened time between the time a page had its reference reset and then tested again. with the shortened cycle time, there tended to be more pages that hadn't a chance to be used and therefor have their reference bit turned on again. as a result, each time the selection was called on a page fault, fewer pages had to be examined before finding one w/o its reference set. if the avg. number of pages examined per page fault was reduced ... then it increased the total time to cycle through all pages (allowing more pages to have a chance to be used and have their reference bit set). part of the vm370 morph was that it change the page scanning from real storage address (which basically distributed virtual pages fairly randomly) to a link list. one of the side-effects of the link list management was that it drastically disturbed the basic premise under which clock operated. with the virtual pages position in the list constantly being perturbed ... it was no longer possible to assert that the time between a page had its reference reset and not taken and the time it was examined again ... was in anyway related to the avg. time it took clock to cycle through all pages. basically a single reference bit represented some amount of activity history related to the use of that specific page. in clock the avg. amount of activity history that a reference bit represents is the interval between the time the bit was reset and the time it was examined again. on the avg. that is the interval that it takes clock to cycle through all pages ... and is approximately the same for all pages. if pages were being constantly re-ordered on the list (that is being used by clock to examine pages) ... there is much less assurance that the inverval between times that a specific page was examined in any way relates to the avg. elapsed time it takes clock to make one complete cycle through all pages. this perturbs and biases how pages are selected in ways totally unrelated to the
Re: virtual memory
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Don't forget the single-address-space systems, of which the iSeries > (nee AS/400) is perhaps the most commercially successful example. Just > because process-per-address space is fashionable, doesn't mean it's > the only viable approach. precursor to as/400 was the s/38 ... which folklore has having been a bunch of future system people taking refuge in rochester after FS was killed. reference to future system effort earlier in this thread. http://www.garlic.com/~lynn/2006i.html#32 virtual memory misc. collected postings referencing FS. I didn't make myself particularly popular with the FS crowd at the time, drawing some parallel between their effort and a cult film that had been playing non-stop for several years down in central sq. http://www.garlic.com/~lynn/subtopic.html#futuresys the transition of as/400 from cisc architecture to power/pc ... involved a lot of hangling during the 620 chip architecture days ... with rochester demanding a 65th bit to be added to the 64bit virtual addressing architecture (they eventually went their own way). a few past posts mentioning 620, 630 and some of the other power/pc activities: http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition) http://www.garlic.com/~lynn/2001i.html#24 Proper ISA lifespan? http://www.garlic.com/~lynn/2001i.html#28 Proper ISA lifespan? http://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan? http://www.garlic.com/~lynn/2004q.html#40 Tru64 and the DECSYSTEM 20 http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design http://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design i've perodically mused that the migrations of as/400 to power/pc was somewhat fort knox reborn. circa 1980 there was an effort to migrate a large number of the internal microprocessors to 801 chips. one of these was to have been 370 4341 follow-on. I managed to contribute to getting that effort killed ... as least so far as the 4381 was concerned. misc. collected posts mentioning 801, fort knox, romp, rios, somerset, power/pc, etc http://www.garlic.com/~lynn/subtopic.html#801 for misc. other lore, the executive we had been reporting to when we started the ha/cmp product effort ... moved over to head up somerset ... when somerset was started (i.e. the apple, motorola, ibm, et all effort for power/pc). http://www.garlic.com/~lynn/subpubtopic.html#hacmp the initial port of os/360 (real memory) mvt to 370 virtual memory was referred to as os/vs2 SVS (single virtual storage). the original implementation was an mvt kernel laid out in a 16mbyte virtual memory (somewhat akin to mvt running in 16mbyte virtual machine) with virtual memory and page handler crafted onto the side ... and CCWTRANS borrowed from cp67. the os/360 genre was real memory orientation with heavy dependancy on pointer passing in majority of the APIs ... being able to process any kind of service request required directly addressing parameter list pointed to by the passed pointer. this was, in part, big part of having address space for os/360 operation. The application paradigm involving I/O was largely dependent on direct transfer from/to application allocated storage. Application and library code would build I/O programs with the "real" address locations that were assigned to the application. Transition to virtual memory environment, had the majority of application I/O involved passing address pointers to these application build I/O programs with "application" allocated storage addresses. In the real address world, the kernel would schedule some I/O permission restrictions and then transfer control directly to the application I/O program. In the transition to the virtual address space world ... all of these application I/O programs were now specifying virtual addresses ... not real addresses. CP67's kernel "CCWTRAN" handled the building of "shadow" I/O program copies ... fixing the required virtual pages in real storage and translating all of the supplied virtual address into real address for execution of the "shadow" I/O programs. recent post about CCWTRAN and shadow I/O programs http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT SVS evolved into MVS ... there was a separate address space for every application. However, because of the heavy pointer passing paradigm, the "MVS" kernel actually occupied 8mbytes of every application 16mbyte virtual address space. There was some additional hacks required. There were some number of things called subsystems that were part of most operational environments. They existed outside of the kernel (in their own virtual address space) ... but in the MVT & SVS worlds,
Virtual memory implementation in S/370 (a.f.c x-post)
> The recent thread about virtual memory sparked a (kind of) > idle question: why did the implementation in the S/370 > have a two-level scheme (segment and page)? My original > thought was that it facilitated definition of discontiguous > parts of an address space. Well, mostly it is because smaller systems don't have enough real memory to hold a one level page table. The segment/page system allows page tables to be paged out, with the invalid bit in the segment table. VAX uses a two level system where page tables are paged. There is kernel space, which isn't paged and holds the first level tables referencing pagable second level tables. z/Archtecture has three levels. Actually, Region First Table Region Second Table Region Third Table Segment Table Page Table Richard Corak
Re: Virtual memory implementation in S/370 (a.f.c x-post)
On Thu, 11 May 2006 11:08:56 -0700, glen herrmannsfeldt <[EMAIL PROTECTED] .edu> wrote: >Marten Kemp <[EMAIL PROTECTED]> writes: >> The recent thread about virtual memory sparked a (kind of) >> idle question: why did the implementation in the S/370 >> have a two-level scheme (segment and page)? My original >> thought was that it facilitated definition of discontiguous >> parts of an address space. > >Well, mostly it is because smaller systems don't have enough >real memory to hold a one level page table. > >The segment/page system allows page tables to be paged out, >with the invalid bit in the segment table. > >VAX uses a two level system where page tables are paged. >There is kernel space, which isn't paged and holds the first >level tables referencing pagable second level tables. > >z/Archtecture has three levels. > >-- glen > = == == Actually, z/Architecture has 5 levels. So far, the existed hardware only uses 3 of them.
Re: virtual memory
"kim kubik" <[EMAIL PROTECTED]> writes:
> There are (at least) two overlapping meanings of the phrase "virtual
> memory" here: a virtual (i.e., non-real) memory address and a
> virtual eXtention ("X" as in VAX) of memory out to disk. Most
> people seem to use the latter meaning.
>
> The first, virtual memory addressing (dividing up of RAM into fixed
> sized pages) is in most cases a big win: drastic decrease in memory
> fragmentation.
>
> Extending RAM out to disk pages adds all the cute PhD thesis project
> benchmarkable optimizations: page size, replacement algorithms,
> thrash minimization, etc. In an early attempt a compiling TeX in SUN
> the person finally shut down the machine after 36 hours, noting the
> paging daemon was taking up more and more of cpu time and eventually
> might take all of it.
the post did describe a case where virtual memory was used
to address fragmentation problem
http://www.garlic.com/~lynn/2006i.html#22 virtual memory
some subsequent drift on this thread in a.f.c.
http://www.garlic.com/~lynn/2006i.html#23 virtual memory implementation in
S/370
http://www.garlic.com/~lynn/2006i.html#24 virtual memory implementation in
S/370
i had done a bunch of the paging stuff as an undergraduate in the 60s
... which was picked up and shipped in cp67 product.
http://www.garlic.com/~lynn/subtopic.html#wsclock
decade plus later there was some conflict around somebody's stanford
phd on global lru replacement (work that i had done as an undergraduate in
the 60s) vis-a-vis local lru replacements. some past posts mentioning
the conflict.
http://www.garlic.com/~lynn/93.html#4 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
http://www.garlic.com/~lynn/2001c.html#10 Memory management - Page replacement
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login
Names
http://www.garlic.com/~lynn/2003k.html#8 z VM 4.3
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small
clusters
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before
the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the
line
http://www.garlic.com/~lynn/2005n.html#23 Code density and performance?
http://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s
i had also done this stuff with dynamica adaptive scheduling
(scheduling policies included fair share) ... and scheduling to the
bottleneck
http://www.garlic.com/~lynn/subtopic.html#fairshare
much of it was dropped in the morph from cp67 to vm370 ... but
i was allowed to reintroduce it as the "resource manager"
which became availble 11may76
http://www.garlic.com/~lynn/2006i.html#26 11may76, 30 years, (re-)release of
resource manager
around this time, i was starting to notice the decline of relative
disk system performance ... and significant increase in amount of
available real storage ... and being able to start to use real storage
caching to compensate for the decline in relative disk system
performance
i started making some comments about it and the disk division
eventually assigned their performance group to refute the comments.
the performance group came back and observed that i had slightly
understated the problem.
misc. past posts on the subject:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the
Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other
irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to
Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was:
Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran
as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://ww
Virtual memory implementation in S/370 (a.f.c x-post)
Marten Kemp <[EMAIL PROTECTED]> writes: > The recent thread about virtual memory sparked a (kind of) > idle question: why did the implementation in the S/370 > have a two-level scheme (segment and page)? My original > thought was that it facilitated definition of discontiguous > parts of an address space. Well, mostly it is because smaller systems don't have enough real memory to hold a one level page table. The segment/page system allows page tables to be paged out, with the invalid bit in the segment table. VAX uses a two level system where page tables are paged. There is kernel space, which isn't paged and holds the first level tables referencing pagable second level tables. z/Archtecture has three levels. -- glen
Virtual memory implementation in S/370 (a.f.c x-post)
Marten Kemp <[EMAIL PROTECTED]> writes: > The recent thread about virtual memory sparked a (kind of) > idle question: why did the implementation in the S/370 > have a two-level scheme (segment and page)? My original > thought was that it facilitated definition of discontiguous > parts of an address space. re: http://www.garlic.com/~lynn/2006i.html#22 virtual memory http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370 i had also done page migration as well as "table" migration ... which were released in my resource manager product ... the blue letter product announcement gives product release as 11may76 ... 30 years ago tomorrow. partial reproduction of the resource manager blue letter: http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager page migration would look make judgements about different speed paging devices ... and if it found "high" speed paging devices filling up, it would start looking for idle virtual pages (resident on "high" speed devices), that it could migrate to slower speed devices. when real storage started getting constrained ... it would also look for idle portions of virtual address spaces. each 64kbyte virtual segment consumed ten bytes of real storage, 2bytes for the page table entry and 8bytes of adminstrative stuff (shadow storage protect keys, and location on paging device for the virtual page). for "idle" segments, it would turn on the invalid bit in the segment table entry, write the administrative stuff to special disk locations, and then discard the real memory for the page table and administrative stuff ... typically picking up 160bytes of real storage per 64kbyte of idle virtual address space or 2560bytes of real storage per 1mbyte of idle virtual address space ... little over 4kbytes of real storage per 2mbytes of idle virtual address space. the defined virtual address space might or not be contiguous ... but the segment table could have large gaps in the pointers to page tables ... potentially because the space wasn't defined in the particular virtual address space ... or because the virtual address space area was deamed to be idle at the moment and the associated tables had been removed from real storage. the administrative table containing the disk backing store address for virtual pages (and the shadow storage protect keys) was called a SWAPTABLE ... so the feature allowing the SWAPTABLE to be removed from real storage was called SWAPTABLE migration or paging SWAPTABLEs. a few other posts mentioning SWAPTABLE migration: http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#35 Charging Time http://www.garlic.com/~lynn/2006.html#36 Charging Time ... and a few posts mentioning shadowing process: http://www.garlic.com/~lynn/2005h.html#17 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2006i.html#10 Hadware Support for Protection Bits: what does it really mean? -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Virtual memory implementation in S/370 (a.f.c x-post)
Marten Kemp <[EMAIL PROTECTED]> writes: > The recent thread about virtual memory sparked a (kind of) > idle question: why did the implementation in the S/370 > have a two-level scheme (segment and page)? My original > thought was that it facilitated definition of discontiguous > parts of an address space. 370 virtual memory architecture segment & page tables. 360/67 provided for both 24-bit virtual addressing and 32-bit virtual addressing (in its segment/page virtual memory structure). the introduction of virtual memory on 370 was just 24-bit virtual addressing with segment and page tables, originally with 1mbyte and 64kbyte segment options as well as 4kbyte and 2kbyte page options. the original 370 virtual memory architecture also had segment protection and some selective invalidate instructions. these additional features were dropped to help get the virtual memory hardware retrofit to 370/165 back on schedule. in the morph from cp67/cms to vm370/cms, cms had been restructured to take advantage of "shared segments" (single copy of the same virtual memory page in physical storage for multiple different virtual address spaces) with the segment protect feature. when segment protect was dropped from 370 virtual memory architecture, the protection of these shared pages had to be reworked. more than 24-bit virtual addressing wasn't re-introduced until 370-xa with the 3081. I had done a page-mapped filesystem for CMS, which included compatibility for existing CMS filesystem API http://www.garlic.com/~lynn/subtopic.html#mmap It also included a number of extended features allowing page-mapped objects (shared & non-shared) to appear at arbitrary virtual address locations. the same shared (segment) object could even appear at different virtual addresses in different virtual address space. this required a lot of fiddling with the prevalent 360/370 software use of address constants. Lots of posts mentioning the fiddling with address constants http://www.garlic.com/~lynn/subtopic.html#adcon Only a small subset of the virtual memory object support was ever released called DisContiguous Shared Segment (DCSS). The generalized virtual memory object support and the page mapped filesystem support was never released. various posts mentioning the segment protect issue: http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line http://www.garlic.com/~lynn/2005h.html#9 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new? http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment http://www.garlic.com/~lynn/2005o.html#10 Virtual memory and memory protection http://www.garlic.com/~lynn/2006.html#13 VM maclib reference http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory? http://www.garlic.com/~lynn/2006b.html#39 another blast from the past http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean? ... and misc. past posts mentioning dcss: http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390 http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...) http://www.garlic.com/~lynn/2002o.html#25 Early computer games http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning) http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why? http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story http://www.garlic.com/~lynn/2003o.html#42 misc. dmksnt http://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic http://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism http://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software? http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing http://w
