Re: drop_caches in SLES 9 ?
On Fri, May 8, 2009 at 3:26 PM, Brad Hinson wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=444961 > > Patch was committed to 2.6.25-mm1, so for anyone making heavy use of > drop_caches, make sure to update to RHEL 5.3 (or the kernel at least). Right. Thanks Brad. I should have taken the time to look it up from my notes. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES 10 SP2 - where do I find documentation on Access Control Table (ACT)
>>> On 5/8/2009 at 1:45 PM, Sam Bass wrote: > I think that we need to use /etc/lvm/lvm.conf to limit what z/linux can > see. That would be helpful, but you'll need to make sure that, whatever persistent device naming method you use, you don't wind up with duplicate device names between your LPARs and your z/VM guests. For convenience of cloning, I usually recommend using the by-path names, but that might result in collisions in your case. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES 10 SP2 - where do I find documentation on Access Control Table (ACT)
I think that we need to use /etc/lvm/lvm.conf to limit what z/linux can see. Sam -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Mark Post Sent: Friday, May 08, 2009 11:41 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: SLES 10 SP2 - where do I find documentation on Access Control Table (ACT) >>> On 5/8/2009 at 12:22 PM, Sam Bass wrote: > We have a LPAR z/Linux SLES 10sp1 and a z/VM z/Linux SLES 10sp2. > > We don't want these to see each others disk (LVM). > Right now I have them on different channels on our z9. > > I found some old documentation on ACT but I cannot find exactly how to > use it. Are you talking about DASD volumes, or SCSI over FCP disks? If the latter, hopefully your SAN switch support N-port ID Virtualization (NPIV), which eliminates the problem of two separate LPARs or guests looking like the same system to the switch. If you're talking about DASD, then you just make sure your I/O gens don't have the other LPAR's volumes in it. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES 10 SP2 - where do I find documentation on Access Control Table (ACT)
Have you looked at the "Configuration Utility for FCP LUN Access Control User's Guide" SC33-8280-00? it explains how to install and use the Configuration Utility for FCP LUN Access Control which you'd use to create and maintain ACT's > -Original Message- > From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of > Sam Bass > Sent: Friday, May 08, 2009 12:22 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: SLES 10 SP2 - where do I find documentation on Access > Control Table (ACT) > > We have a LPAR z/Linux SLES 10sp1 and a z/VM z/Linux SLES 10sp2. > > We don't want these to see each others disk (LVM). > Right now I have them on different channels on our z9. > > I found some old documentation on ACT but I cannot find exactly how to > use it. > > ftp://ftp.software.ibm.com/eserver/zseries/zos/vse/pdf3/wavv05/Using_zV > M > _in_a_SCSI_Environment.pdf > > Sam Bass > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 > or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES 10 SP2 - where do I find documentation on Access Control Table (ACT)
It is zfcp. No we do not have NPIV turn on since we just upgraded the SVCs this week (and the old one did not support NPIV (IBM 2145 firmware v3) and the new SVCs are loaded with latest V4. We will have the same issue of access once we move the LPAR z/Linux under z/VM. Sam -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Mark Post Sent: Friday, May 08, 2009 11:41 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: SLES 10 SP2 - where do I find documentation on Access Control Table (ACT) >>> On 5/8/2009 at 12:22 PM, Sam Bass wrote: > We have a LPAR z/Linux SLES 10sp1 and a z/VM z/Linux SLES 10sp2. > > We don't want these to see each others disk (LVM). > Right now I have them on different channels on our z9. > > I found some old documentation on ACT but I cannot find exactly how to > use it. Are you talking about DASD volumes, or SCSI over FCP disks? If the latter, hopefully your SAN switch support N-port ID Virtualization (NPIV), which eliminates the problem of two separate LPARs or guests looking like the same system to the switch. If you're talking about DASD, then you just make sure your I/O gens don't have the other LPAR's volumes in it. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES 10 SP2 - where do I find documentation on Access Control Table (ACT)
>>> On 5/8/2009 at 12:22 PM, Sam Bass wrote: > We have a LPAR z/Linux SLES 10sp1 and a z/VM z/Linux SLES 10sp2. > > We don't want these to see each others disk (LVM). > Right now I have them on different channels on our z9. > > I found some old documentation on ACT but I cannot find exactly how to > use it. Are you talking about DASD volumes, or SCSI over FCP disks? If the latter, hopefully your SAN switch support N-port ID Virtualization (NPIV), which eliminates the problem of two separate LPARs or guests looking like the same system to the switch. If you're talking about DASD, then you just make sure your I/O gens don't have the other LPAR's volumes in it. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES 10 SP2 - where do I find documentation on Access Control Table (ACT)
We have a LPAR z/Linux SLES 10sp1 and a z/VM z/Linux SLES 10sp2. We don't want these to see each others disk (LVM). Right now I have them on different channels on our z9. I found some old documentation on ACT but I cannot find exactly how to use it. ftp://ftp.software.ibm.com/eserver/zseries/zos/vse/pdf3/wavv05/Using_zVM _in_a_SCSI_Environment.pdf Sam Bass -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
2009-05-08 Recommended Linux on System z code and manuals drop to developerWorks
Please refer to: http://www.ibm.com/developerworks/linux/linux390/whatsnew.html ... for the 2009-05-08 change summary with code patches and new/ updated documentation. * end of message Mit freundlichen Grüßen / Kind regards Gerhard Hiller Systems Software Management IBM Systems & Technology Group, Systems Software Development Phone: +49-7031-16-4388 IBM Deutschland Fax: +49-7031-16-3545 Schoenaicher Str. 220 E-Mail: ghil...@de.ibm.com 71032 Boeblingen Germany IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 <><><><><><><>
Re: DR and Linux native lpar
How about the LPARNAME in /proc/sysinfo. Ron Sent via BlackBerry by AT&T -Original Message- From: "Alan Schilla (OET)" Date: Fri, 8 May 2009 08:10:06 To: LINUX-390@VM.MARIST.EDU Subject: Re: DR and Linux native lpar I have been giving this some thought lately too. I have been planning to extract the cpu serial number from /proc/cpuinfo. This should tell me whether or not I am on my normal production hardware. The problem I have with this is remembering that I need to change the script when we move zVM or Linux to a different system or replace hardware. That's the scary part. I am looking for something system wide yet better controllable that cpuid. Al Schilla Systems Programmer Enterprise Technology Services Office of Enterprise Technologies phone: 651-201-1216 email: alan.schi...@state.mn.us -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Scott Rohling Sent: Thursday, May 07, 2009 2:07 PM To: LINUX-390@vm.marist.edu Subject: Re: DR and Linux native lpar Sure .. the trick is knowing when to use the DR version in your Linux scripts. Not sure /proc/cpuinfo would help.. maybe passing a parm at boot and looking at /proc/cmdline ? After determining which version/CPU/whatever you are on - your scripts can hit the appropriate network config files and change them if they are not correct for 'where' you are. Not sure if this is what you wanted though? Scott On Thu, May 7, 2009 at 12:29 PM, Michael Wickman wrote: > We are in the design phase of building our own disaster recovery site. > DASD will be mirrored or flashed. We don't have VM, so have SUSE > release 9 native lpar. Is it possible to have some logic in the IPL > startup to specify those unique things like IP address or a separate > script we can invoke when the DR site version is used. > > Thanks. > > Mike Wickman > > > > > > > > > "This email is intended to be reviewed by only the intended recipient > and may contain information that is privileged and/or confidential. > If you are not the intended recipient, you are hereby notified that > any review, use, dissemination, disclosure or copying of this email > and its attachments, if any, is strictly prohibited. If you have > received this email in error, please immediately notify the sender by > return email and delete this email from your system." > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: drop_caches in SLES 9 ?
Rob van der Heij wrote: 2009/5/8 Tomasz Westrych : How to clear memory cache in Sles 9 ? In SLES10 you can do "echo 3 > /proc/sys/vm/drop_caches". In SLES9 I, don't see drop_caches. We have z/VM 5.4 + SLES9 version 2.6.5-7.244-s390x. Right. This is a more recent addition to Linux memory management, and it's not available in the older kernels. Be aware that it does not really help you in reducing your real memory requirements when running on z/VM. The reason is that z/VM is not aware that Linux has freed up those pages, and z/VM will still retain the data. In some cases, doing this will actually *increase* your real memory requirements. If you want to do such things, look at CMM-1 (which is in SLES9). It's really just a diagnostics tool, for example to make sure that your benchmark is no cheating with a lot of data already loaded in cache. It may also be helpful to understand the base requirements of an application. And for those of the other side listening in: there is a bug in one of the RHEL5 kernels that causes Linux in a loop when you use drop_caches in a very large server. Rob Sounds like this bug: https://bugzilla.redhat.com/show_bug.cgi?id=444961 Patch was committed to 2.6.25-mm1, so for anyone making heavy use of drop_caches, make sure to update to RHEL 5.3 (or the kernel at least). -- Brad Hinson Sr. Support Engineer Lead, System z Red Hat, Inc. (919) 754-4198 www.redhat.com/z -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DR and Linux native lpar
I have been giving this some thought lately too. I have been planning to extract the cpu serial number from /proc/cpuinfo. This should tell me whether or not I am on my normal production hardware. The problem I have with this is remembering that I need to change the script when we move zVM or Linux to a different system or replace hardware. That's the scary part. I am looking for something system wide yet better controllable that cpuid. Al Schilla Systems Programmer Enterprise Technology Services Office of Enterprise Technologies phone: 651-201-1216 email: alan.schi...@state.mn.us -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Scott Rohling Sent: Thursday, May 07, 2009 2:07 PM To: LINUX-390@vm.marist.edu Subject: Re: DR and Linux native lpar Sure .. the trick is knowing when to use the DR version in your Linux scripts. Not sure /proc/cpuinfo would help.. maybe passing a parm at boot and looking at /proc/cmdline ? After determining which version/CPU/whatever you are on - your scripts can hit the appropriate network config files and change them if they are not correct for 'where' you are. Not sure if this is what you wanted though? Scott On Thu, May 7, 2009 at 12:29 PM, Michael Wickman wrote: > We are in the design phase of building our own disaster recovery site. > DASD will be mirrored or flashed. We don't have VM, so have SUSE > release 9 native lpar. Is it possible to have some logic in the IPL > startup to specify those unique things like IP address or a separate > script we can invoke when the DR site version is used. > > Thanks. > > Mike Wickman > > > > > > > > > "This email is intended to be reviewed by only the intended recipient > and may contain information that is privileged and/or confidential. > If you are not the intended recipient, you are hereby notified that > any review, use, dissemination, disclosure or copying of this email > and its attachments, if any, is strictly prohibited. If you have > received this email in error, please immediately notify the sender by > return email and delete this email from your system." > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cpuplugd-setting CPU_MIN to 1
On Fri, May 8, 2009 at 1:25 PM, Harder, Pieter wrote: > And now for the really stupid question: does enabling cpuplugd with CPU_MIN=1 > actually gain something? I have turned it on for one of my SAP dyadics and my > idle level seems to have gone up instead of down. I now see cpu spikes at the > cpuplugd UPDATE interval that aren't there with cpuplugd disabled. Obviously > running cpuplugd costs something and falls into the chapter of disabling > unneeded services. This only makes sense when the processing saved in CP > amounts to more than the cost of running cpuplugd. I see more stupid answers than stupid questions, but that may be because I often give the answers ;-) When switching off the excessive virtual CPUs makes the difference to drop from queue, it may be well worth the investment of some extra CPU usage to manage that. So you pay some CPU to save storage. If it does not save storage, you might not want to spend CPU on it. The other motivations for it don't apply well to Linux on z/VM. Something like cpuplugd is an ugly hack. I wish Linux would not engage all virtual CPUs when the workload does not take advantage from it. Simply loading an enabled wait PSW would be enough. The idea behind CPU affinity that causes this does not apply to Linux on z/VM as I see it. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cpuplugd-setting CPU_MIN to 1
>With Linux on z/VM I do like the idea that reduced >number of CPUs may improve chances of the virtual machine drop from >queue nicely. But recent SAP releases have stuff that makes even the >virtual 1-way stay in-queue, so there it does not help anymore. And now for the really stupid question: does enabling cpuplugd with CPU_MIN=1 actually gain something? I have turned it on for one of my SAP dyadics and my idle level seems to have gone up instead of down. I now see cpu spikes at the cpuplugd UPDATE interval that aren't there with cpuplugd disabled. Obviously running cpuplugd costs something and falls into the chapter of disabling unneeded services. This only makes sense when the processing saved in CP amounts to more than the cost of running cpuplugd. Best regards, Pieter Harder pieter.har...@brabantwater.nl tel +31-73-6837133 / +31-6-47272537 Brabant Water N.V. Postbus 1068 5200 BC 's-Hertogenbosch http://www.brabantwater.nl Handelsregister: 16005077 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cpuplugd-setting CPU_MIN to 1
On Mon, May 4, 2009 at 5:21 PM, Ron Foster at Baldor-IS wrote: > I have been using the supplied example that had the minimum number of > CPUs set to 2. I don't think there is a real reason for having the minimum at 2. Earlier this week I raised the question "why would you ever set the minimum higher than 1" and the response was basically that some applications use the information about the number of CPUs. Those applications may get confused when you take away CPUs that they thought they would have. The other reason I see to do it is to prevent z/VM 5.4 share redistribution mess with your business objectives. Your under-utilized server will effectively take resources away from another busy server with the same importance for the business. > Now I am looking at our production SAP dialog servers. Each one has two > CPUs defined to it. This is because during some times of the month, at > some times of the day, one CPU cannot handle the load. Right. if your peak is more than one virtual CPU and you have enough CPU resources to spend on the workload, then you need more virtual CPUs. > Now I know that defining more CPUs than you need is not a good thing. > And most of the time, the nine servers that I am looking at only need > one CPU. I am wondering if anyone has seen any ill effects from > changing cpuplugd to allow the minimun number of CPUs to be 1. I see cpuplugd mainly to have value when you run in LPAR and want L-shaped LPARs. With Linux on z/VM I do like the idea that reduced number of CPUs may improve chances of the virtual machine drop from queue nicely. But recent SAP releases have stuff that makes even the virtual 1-way stay in-queue, so there it does not help anymore. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: drop_caches in SLES 9 ?
2009/5/8 Tomasz Westrych : > How to clear memory cache in Sles 9 ? In SLES10 you can do "echo 3 > > /proc/sys/vm/drop_caches". > In SLES9 I, don't see drop_caches. > > We have z/VM 5.4 + SLES9 version 2.6.5-7.244-s390x. Right. This is a more recent addition to Linux memory management, and it's not available in the older kernels. Be aware that it does not really help you in reducing your real memory requirements when running on z/VM. The reason is that z/VM is not aware that Linux has freed up those pages, and z/VM will still retain the data. In some cases, doing this will actually *increase* your real memory requirements. If you want to do such things, look at CMM-1 (which is in SLES9). It's really just a diagnostics tool, for example to make sure that your benchmark is no cheating with a lot of data already loaded in cache. It may also be helpful to understand the base requirements of an application. And for those of the other side listening in: there is a bug in one of the RHEL5 kernels that causes Linux in a loop when you use drop_caches in a very large server. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
drop_caches in SLES 9 ?
Hi all, How to clear memory cache in Sles 9 ? In SLES10 you can do "echo 3 > /proc/sys/vm/drop_caches". In SLES9 I, don't see drop_caches. We have z/VM 5.4 + SLES9 version 2.6.5-7.244-s390x. Thanks, Tom -- Dzwonki na komorkj! Sprawdz >> http://link.interia.pl/f2152 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
