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 IBMVM@LISTSERV.UARK.EDU 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 thedefault 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
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 IBMVM@LISTSERV.UARK.EDU 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 thedefault 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
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
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 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
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] OMTo 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: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
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 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
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
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
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
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
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 IBMVM@LISTSERV.UARK.EDU 08/06/2008 02:06 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 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
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
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
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
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
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
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
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
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, 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 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, 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
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 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 thedefault 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
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
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
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
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
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? G 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
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? G 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
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 G). 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 G. (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 G. 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
-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 G. 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
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
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
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 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. groan! Alan Altmark z/VM Development IBM Endicott
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. groan! 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
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
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
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
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
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
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]
