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'd rather be flying
I don't know. Looks like a FUD campaign to me.
Part 1 of the article (series) made a big deal of the 41,400 demo -- that nobody has tried to say is realistic.
That's ok, but Murphy got ridiculous in trying to intimate that each of those images had an 8 megabyte working set and that swapping those images in to handle timer pops would generate 30 gigabytes per second -- or maybe it was 30000 gigabytes per second, I don't remember -- of paging activity. Trouble is, apache and Linux together might have that big a memory footprint, but idle processes will have a much smaller working set, one measured in kilobytes. Each image will demand page only those pieces of the address space required to process the work being done. I don't think the interrupt handler and dispatcher and apache's own dispatch loop occupy that much code.
In the second section, he talks about workloads losing randomness as more and more work gets piled on. The opposite is true: they gain randomness. He's certainly right that interactive workloads have definite patterns of peaks and valleys, but that's very different from losing randomness in very small time increments, and it is that randomness that lets a mainframe (or any large processor -- including Unix) do more with less horsepower than clusters.
There's a lot in his article that I don't understand, but his treatment of things that I do understand leaves me unwilling to trust the rest.