Yes, that's what we would do. And so if not taken all the way off of vm at that moment, it would only have 6G of standby until the next time that happened (generally no longer than a month with the amount of patching we do around here).
-----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Michael MacIsaac Sent: Monday, August 29, 2016 9:46 AM To: [email protected] Subject: Re: [LINUX-390] Linux and VM memory operations and The Principle of Least Astonishment Marcy, Yes, that helps. So let's say a virtual machine has 2G of initial, 8G of STANDBY, so thus the max would have to be at least 10G. Then a user says 'I need 2G more'. So you'd go to 4G initial, stay at 8G STANDBY for a new 12G max? Thanks. -Mike On Mon, Aug 29, 2016 at 12:38 PM, Marcy Cortes < [email protected]> wrote: > So here we pretty much just leave standby alone at 8G. > We wouldn't take any standby away if we increased the memory. We still > want to have some there to be able to add in an emergency situation > (and we have had to do that when apps had a memory leak but couldn't > take a recycle). > > Does that answer what you are looking for? > > > -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On Behalf Of > Michael MacIsaac > Sent: Sunday, August 28, 2016 7:50 AM > To: [email protected] > Subject: [LINUX-390] Linux and VM memory operations and The Principle > of Least Astonishment > > Wikipedia says the “Principle of least astonishment” is that systems > (software) should behave in a manner consistent with how users of that > component are likely to expect it to behave, i.e., users should not be > astonished at the way it behaves. > > I’m trying to apply this principle to memory operations on z/VM and > Linux in zoom line commands. > > I believe Linux running on z/VM has 3 types of memory, all of which > can be > different: > 1) That defined in the user directory > 2) That defined in CP for a running system > 3) That defined in and used by a running Linux > > While they can all be different, it's probably best to keep all three > in sync so you can say "That Linux system has <amount> of memory." > > Then to complicate matters, there are maximum and 'standby' amounts, > the latter of which is necessary if memory is to be added dynamically > to running Linux systems. The initial, maximum and standby can also > get out of sync in the user directory and again it's probably best > that they don't > > First some terminology. > -) 'soft reboot' - Linux 'init 6' - does not log off/on virtual > machine > -) 'hard reboot' - Linux halt, logoff, logon, boot > > So, for some hopefully intuitively named line commands, is this how > you'd expect them to behave? > > zaddmemory linux1,linux2 1g > Add 1g to user directory initial, CP and Linux memory on nodes > linux1 and linux2. > If 'COMMAND DEF STOR <init> STANDBY <stby>' is found, add to <init>, > subtract from <stby> > > zrmmemory linux1,linux2 1g > Remove 1g from user directory initial, CP and Linux memory on nodes > linux1 and linux2. > If 'COMMAND DEF STOR <init> STANDBY <stby>' is found, subtract from > <init>, add to <stby> > > zaddmemory --initial linux1 1g > Add 1g to user directory initial only => take effect after hard reboot. > If 'COMMAND DEF STOR <init> STANDBY <stby>' is found, add to <init>, > subtract from <stby> > > zaddmemory --temp linux1 1g > Add 1g to running linux1 only => will be gone after hard or soft > reboot, no change to user directory. > > zsetmemory --maximum linux1 8g > Set linux1 maximum meomory to 8G in user directory. > If 'COMMAND DEF STOR <init> STANDBY <stby>' is found, set <stby> to > <max> > - <init>. > > zsetmemory --standby linux1 7G > Set linux1 standby memory only to 7G. > > Let me add some feedback as I think about the last example - setting > STANDBY only would by definition get settings out of sync, so maybe it > would be astonishing to allow such an option. > > Thanks for any feedback. > > -Mike MacIsaac > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
