Re: HugePage support with RHEL
On 9/2/2011 7:37 AM, Martin Schwidefsky wrote: There is no documentation for z/VM as the edat facility is not supported. The emulation for large pages takes place in the Linux guest. Looking at IBM past support for new hardware in guests of z/VM, I would suggest that it will be supported in z/VM 7.1 or before. Look for edat facility support to be added in a as yet unannounced point release of z/VM 6.?. Also, IBM probably will not talk about it until they are ready to announce it. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Mobile: (405) 464-7818 email: stevef%doc.state.ok.us -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HugePage support with RHEL
On Fri, 2 Sep 2011 07:35:56 -0400 "CHAPLIN, JAMES (CTR)" wrote: > I almost gave up hope on HughPages due to all our zLinux Guests run > under zVM, and we like using zVM to control the swapping as best as > possible. I do have two follow-up questions: > > 1) Can you point me to any reference material dealing with HugePages > with zVM (v6.1) where I can start my "homework" on the topic? I did a > search online of IBM zVM 6.1 doc on HugePages, Large Pages and came up > with nothing. There is no documentation for z/VM as the edat facility is not supported. The emulation for large pages takes place in the Linux guest. > 2) What is required or needs to be done to enable edat in zLinux from > the zVM side? Again, would you be able to point me to any doc in the zVM > side? How do we get the "edat facility", is it hardware or a setting in > either the SE or HMC with the LPAR definition, or in the IODF? You cannot enable the edat facility under z/VM for a Linux guest (and you won't see "edat" in the cpu features) but you can still use large pages in the Linux guest. Just specify the hugepages= kernel parameter. The Linux kernel will automatically use the large page emulation if the edat facility is missing. You may want to look at the "Large Page Support" chapter in "Linux on System z Device Drivers, Features and Commands": http://public.dhe.ibm.com/software/dw/linux390/docu/lk39dd11.pdf -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HugePage support with RHEL
Thanks Martin, I almost gave up hope on HughPages due to all our zLinux Guests run under zVM, and we like using zVM to control the swapping as best as possible. I do have two follow-up questions: 1) Can you point me to any reference material dealing with HugePages with zVM (v6.1) where I can start my "homework" on the topic? I did a search online of IBM zVM 6.1 doc on HugePages, Large Pages and came up with nothing. 2) What is required or needs to be done to enable edat in zLinux from the zVM side? Again, would you be able to point me to any doc in the zVM side? How do we get the "edat facility", is it hardware or a setting in either the SE or HMC with the LPAR definition, or in the IODF? James Chaplin Systems Programmer, MVS, zVM & zLinux -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Martin Schwidefsky Sent: Friday, September 02, 2011 4:11 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: HugePage support with RHEL On Thu, 1 Sep 2011 15:01:52 -0400 Brad Hinson wrote: > Hi James, > > It appears that in order to use hardware large page support, > Linux must be running in LPAR mode. I can't find anything that > says this is supported in z/VM. Hopefully someone can correct > me if I'm wrong. I can confirm that on a z10 under z/VM 6.1 > I also do not see 'edat' in /proc/cpuinfo, so hugepage support > is emulated in software. You can use large pages in LPAR and under z/VM. In LPAR we have "real" large pages if we have the edat facility. If there is no edat facility or if we are running under z/VM we use large page emulation. There are two benefits to using hugepages: 1) The TLB pressure in reduced by using 1MB frames. To get this benefit the edat facility is required since this needs the large page segment table entries. No love here for z/VM. 2) The memory savings due to the reduced number of page tables. There are two cases: 2a) under LPAR with edat the 1MB frames are directly referenced by the segment table entry, the lowest page table level is not allocated at all. 2b) under z/VM there is no edat facility and no large page segment table entries. Here a single page table for the 1MB frame is allocated which is shared by all users of the large page. The page table overhead to map 2GB of memory: i) without large pages: 1 segment table, 2048 page tables ii) with large page emulation: 1 segment table, 1 page table iii) with edat large pages: 1 segment table In numbers i) 4112 KB, ii) 18 KB, and iii) 16 KB. This number is per process. If your database uses processes for its transactions and maps large share memory areas the memory savings quickly add up. If you have e.g. 128 processes mapping 2GB you'll need for case i) 514 MB, ii) 2.25 MB, and iii) 2 MB. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/ -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Apache worker on SLES11
We use APC ver 3.0.19 for accelerating PHP in SLES. I did download the source and built it manually. Works good, and it increases performance with about 5-10 times. That might do it so you can avoid using worker MPM. _ Tore Agblad System programmer, Volvo IT certified IT Architect Volvo Information Technology Infrastructure Mainframe Design & Development, Linux servers Dept 4352 DA1S SE-405 08, Gothenburg Sweden Telephone: +46-31-3233569 E-mail: tore.agb...@volvo.com http://www.volvo.com/volvoit/global/en-gb/ -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mauro Souza Sent: den 31 augusti 2011 19:53 To: LINUX-390@VM.MARIST.EDU Subject: Apache worker on SLES11 Hi guys! I have a client needing to support about 1000 clients on an Apache2 running on SLES11. Apache currently is using mpm-prefork, and supporting 100 active clients at max. They use PHP, mysql and postgres on the web site, and we are doing a PoC here. Apache is currently using about 60MB per instance, and even if I had not looked into the config file to disable a lot of unused modules in the default config, I think I cannot get the httpd memory usage down to 6MB. My idea was to configure Apache worker, use php-zts and fast-cgi, but I've just found that SLES11 doesn't have php-zts. On Novell's documentation (http://bit.ly/nKgBFl), I've found this: "WARNING: Using PHP Modules with MPMs Not all available PHP modules are thread-safe. Using the worker MPM with mod_php is strongly discouraged." The _strongly discouraged_ part of it is the problem. There's something I can do about it? Mauro http://mauro.limeiratem.com - registered Linux User: 294521 Scripture is both history, and a love letter from God. -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/ -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Migrating UNIX application to z/Linux
A coworker of mine made a presentation in front of an IBM Linux Council on his experience migrating an old C language application from Sun Solaris to Linux on Z. The major effort was in 32 to 64 bit issues, endianness, miscastings, migration across two generations of ANSI standards, application polling differences on new hardware, and surrounding infrastructure differences (gcc, make, etc). However long you think its going to take, double it and change to the next larger units of time. -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HugePage support with RHEL
On Thu, 1 Sep 2011 15:01:52 -0400 Brad Hinson wrote: > Hi James, > > It appears that in order to use hardware large page support, > Linux must be running in LPAR mode. I can't find anything that > says this is supported in z/VM. Hopefully someone can correct > me if I'm wrong. I can confirm that on a z10 under z/VM 6.1 > I also do not see 'edat' in /proc/cpuinfo, so hugepage support > is emulated in software. You can use large pages in LPAR and under z/VM. In LPAR we have "real" large pages if we have the edat facility. If there is no edat facility or if we are running under z/VM we use large page emulation. There are two benefits to using hugepages: 1) The TLB pressure in reduced by using 1MB frames. To get this benefit the edat facility is required since this needs the large page segment table entries. No love here for z/VM. 2) The memory savings due to the reduced number of page tables. There are two cases: 2a) under LPAR with edat the 1MB frames are directly referenced by the segment table entry, the lowest page table level is not allocated at all. 2b) under z/VM there is no edat facility and no large page segment table entries. Here a single page table for the 1MB frame is allocated which is shared by all users of the large page. The page table overhead to map 2GB of memory: i) without large pages: 1 segment table, 2048 page tables ii) with large page emulation: 1 segment table, 1 page table iii) with edat large pages: 1 segment table In numbers i) 4112 KB, ii) 18 KB, and iii) 16 KB. This number is per process. If your database uses processes for its transactions and maps large share memory areas the memory savings quickly add up. If you have e.g. 128 processes mapping 2GB you'll need for case i) 514 MB, ii) 2.25 MB, and iii) 2 MB. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- 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 more information on Linux on System z, visit http://wiki.linuxvm.org/
