Highlights for Linux on POWER
lopblogger 270000WWDS 500 Visits
Just last week we (IBM) enabled the ordering of RHEL AS4 (update 1 level) with any new pSeries server or OpenPower server. Previously, the order was only good for delivery of RHEL AS3. With this ordering we (IBM) has also expanded the orderable options to include 1-3 year and support.[Read More]
Linux on POWER is fully supported by the IBM Advanced Power Virtualization capabilities….depending on a few things.
First you have to be running Novell SUSE SLES 9 or RedHat AS 4 to be enabled for all the virtualization capabilities on POWER. This includes LPARs, DLPARs, V I/O, VLAN, and micro partitioning and shared pools. What does not work, and this is not a limitation of Linux on POWER, but rather a limitation of LINUX 2.6 kernel: Dynamic memory (you can re assign memory to a partition, but it must be rebooted before the memory change is recognized) and Partition Load Manager (this requires hooks in Linux which do not exist yet…..) Other than that, the 2.6 kernel is fully enabled to support the full virtualization..and you can also be running AIX (or on selected models, iOS also).
Now if you choose to run the 2.4 kernel of Linux, it has less functional support of Advanced POWER Virtualization since it is missing the pre-emptive capabilies of 2.6. This means you loose the ability to run dynamic device add/delete (as in disk adapters) and you also loose DLPAR since these obviously need a stop/restart capability in the kernel. Other items of the 2.4 kernel are supported such as LPAR, VLAN, micro partitioning, shared pools…and although not related, also SMT (but that is a different story).
Remember that on the POWER5 systems you can only boot SLES 9 (hence the 2.6 kernel) and RH AS 3 (with limitations above since it is not a preemptive kernel but even though it is 2.4, certain functionality of 2.6 was back ported..such as SMT support), and RH AS 4. Cool…
Now Xen…well it is currently not under development nor test nor porting for POWER. So it appears to be an x86 only application at this time. It is fully capable of being POWER enabled, but the plan does not exist yet for the possible code changes, testing, and etc. Some argue that this is not needed since we have Advanced POWER Virtualization which will have far greater capabilities than Xen for quite a while. But Xen is free, but limited, and APV costs a little. Interesting…less filling costs less, versus, more filling costs more. What do you think we should do with Xen on POWER? Push for availability since it will drive up virtualization of Linux on POWER or continue with the APV plan (which we will do anyway..)?
We all know that Linux is a cool operating system, open, sometimes free (yea right!) and is rapidly growing acceptance. With the 2.6 kernel, the ability Linux to support workload with higher requirements (performance, reliability, security, etc) is now a reality. There are several Linux Distributors "shipping" the 2.6 kernel such as RedHat, Novell SUSE, Debian, etc. One might think that these distributions are all the same but upon closer inspection we can see the kernel is made up of architectual specific code to exploit certain server families. The API of the OS is the same so the ability for applications to run on the various architectures is preserved (as long as you compile the application to the proper instruction set and have the proper run time library support and device drivers). So is it all the same then? I think the answer is a resounding NO. It seems these architectual specific nuances can lead to very dramatic differences in application performance and reliability and sometimes even the ability to run at all.
When the Linux Distributors create a distribution, the major ones today tend to implement a common build process. This is good and if I were them I would do the same. However this may lead to differences and non-optimal execution of programs if you wish to run the application on different architectures. Consider one point only: I/O buffer sizes. If there were a popular architecture that shared memory and I/O over a single bus, I would choose a buffer size that would allow the minimal I/O "interference" with memory access. This usually would mean a relatively small size. If I were then to compile the Linux Kernel for a differnet architecture using the same "defaults", but where the "other" architecture had a separate I/O "bus" and memory "bus", it would not be optimized to the architecture. At least with either a recompile of the kernel or a change to the run time environment, I could move the "standard distribution" to a higher performing version by simply changing the I/O buffer size default. Upon inspection there are several instances where the default build parameters for one architecture will not be optimal on another architecture.
This is just one of several examples of where Linux is Linux is Linux, but it is not the same. In future discussions I will go into more details on these and the relative impact of them....and if you want to get a little more performane out of your Linux Kernel, take a look and see how many print daemons exist for printers you do you run....if you turn them off, you will get a little more performance. I wonder why all these print daemons are really in there anyway?[Read More]