Slashdot Mirror
The Pros and Cons of Mainframe Linux
magellan writes "There is a good article on LinuxWorld.com that goes over some of the pros and cons of Linux on the mainframe. The author, Paul Murphy is an old mainframer and current UNIX user, as well as a frequent contributor to LinuxWorld.com, so he has some good insights.
"
I work in a large datacenter with some very powerful machines, and I just don't see Linux having much of a future on mainframes, at least not without some serious kernel improvements. It is an excellent OS, and would be a good choice for a workstation or a low-end server, but would be a very poor choice for a high-end mainframe machine. The linux kernel is highly configurable and it would certainly be possible to get a Linux kernel running on a massively parallel machine, but this was not what Linux was designed for, and performance would not be on par with other more robust Unices. Linux' inferior TCP/IP stack as well as its inferior handling of multi-threading on a large scale is its major weakness in this area. Until these weaknesses are addressed, I would prefer Solaris, Irix, or HP/UX instead, as they were designed from the ground up with mainframe usage in mind.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
Besides pricing, the more high end the server goes... the more I will lean toward solaris.
I am linux-biased folks are going to / me for this.... but I am speaking from experience.
Funnily enough I just came across this article on ZDNet that talks about how Linux isn't a very good long term server solution. Its here at http://zdnet.com.com/2100-1104-909084.html
First of all, way to go Slashdot, this article has been out for quite some time. It's received a lot of attention on the Linux 390 mailing list as a Sun FUD campaign as it places a fully loaded z900 on par with 80 Dell servers and the zSeries in general on par with mid-range Sun equipment (and others).
;) so it is my job to know about what a z800 can do for us.
First, I'm fairly qualified to talk about what the zServer can do. For those of you who don't remember, I'm one of the guys that helped win a z800 for Clarkson University that will be used in our Open Source Institute. I'm also the technical lead for COSI (whatever that means
Some history, Clarkson University has always had a very good relationship with IBM: they employ a large amount of Clarkson students and graduates (including me, in the Extreme Blue program. So if you think that biases my opinion, well too bad as I've talked with the guys making sure that Linux runs and is fully integrated on the Linux platform and one of the original Linux S390 authors Boas Betzler.
All of these people have real experience with what the zSeries can do, as do I since I've seen it in action. A zServer is unique in the sense that you can (with the right model) run Linux S390, VM, zOS and other guest operating systems in Logical Partitions. These all act independantly of one another just as if they were seperate machines on a network. This is great if you have DB2 with maybe a web frontend because both of those machines can talk at memory speed via HiperSockets and the only outside link is the network connection to the web server, which is at Gigabit speed (did I mention that you can do full speed gigabit with one of these things on multiple interfaces?).
This article basically says that you can take a midrange Sun server and do everything that a z800 can do but much better. I don't know of any Sun Server that can run N Linux clients in a VM at full speed.
They aren't the solution to every problem, but a zServer certainly is a better solution that what is presented in the article. I really don't have the time to go in to detail with everything as it's a lengthy article but suffice it to say that this is no where near 100% accurate.
I think the best that's been done is called the 'tacky' bit (chmod +t) on an executable. Traditionally, that left the executable loaded "in swap", presumably for faster startup.
Implementations vary, and some are literal in that they were little more than a 'cp' from the filesystem onto the swap file and not much else. Some support shared libs, some don't. With big cheap memory, hitting a cached filesystem was far faster than even a linear read from the swapfile. Some were so bad, the +t bit would generally slow performance.
Virtual memory systems, such as DEC's VMS, viewed all executable code files as if they were little swapfiles and would always share image pages on a copy-on-write basis. In effect, the OS opened the image file once for all users on the system. You could also tell the OS to pre-load it by fixing it in your choice of either virtual or physical memory.
I believe Linux is has a partial implementation. It does share resident executable pages across active processes. It might also do something creative with the +t bit, but I have no idea of the implementation. I don't think it has a "complete" implementation, in that you can not pre-load images or fix an image into physical memory, and I don't think it "learns" anything from the first activation experience to speed later ones.
Reading machine code blocks from disk is only part of the 'image activiation' problem. Page tables have to be grown, zero'ed memory has to be allocated, shared resources/libs have to be mapped, etc.,etc. In some cases, if you can pre-load, the system learn by pre-building any number of data structures that can speed multiple re-activations.
Then again, the fastest way to design a maximal performance facility is to activate and initialize both the image, and program logic itself, only once. You can then use IPC type tools to exchange requests with it.
You're looking for 'pinning' or 'the sticky bit', the ability to tell the OS,
"load this executable image in memory and keep it there, next time someone asks for this program use the loaded image, DO NOT LOAD A NEW IMAGE from disk"
This was a manual optimization for early UNIXes. I don't think any modern UNIX uses the sticky bit in this way because that's an optimization that naturally falls out of the page aging algorithms.