z/VM 4.3 introduced the CP SIGNAL command, which lets a privileged user remotely tell Linux guests to shut down. Linux kernel patches exist to respond appropriately to this signal. Since Linux, like other Unix variants, uses a default file system that must be partly rebuilt after an ungraceful shutdown, this eases managing multiple Linux guests on a VM system.
Linux is learning how to share nicely with others. Since Linux never had to deal with a shared environment, it was designed to use all available real hardware resources. When running on VM, that real hardware is actually virtual, shared with other guests. It makes sense for Linux to use all Random Access Memory (RAM) for file cache when running on an Intel system. However, it’s counterproductive for it to use virtual memory for file cache. Both VM and its underlying DASD subsystem are better positioned to make intelligent decisions about what data should be cached; they also do it more efficiently. Making Linux guests smaller often helps performance by reducing overall system paging load.
Linux was designed to wake up every 10 milliseconds (or every millisecond, on later kernels) to look for work. Under VM, this means that idle Linux guests are never truly idle. They wake up frequently and thus are kept in queue and have large working sets (their in-use storage cannot be paged out). A patch exists to suppress this periodic wakeup and efforts are under way to make the Linux scheduler more intelligent about shared environments and to resolve other issues such as use of standard label tapes.
A cultural issue far larger than OCO drivers is the gulf between the groups who must be involved in any Linux project — mainframe, distributed systems, and networking. For decades, these groups have been somewhat at odds, as each has felt the others periodically encroaching on their territory. Sites considering Linux on the mainframe must recognize this and often require management mandate to force cooperation.
Age and terminology can be stumbling blocks. When the grizzled VM system programmer asks the Linux kid, “How much storage do you need for this guest?” and the answer is, “Oh, six gig oughta do it,” they’re speaking different languages. One means memory; the other means disk space. Even there, the terms are different: DASD vs. disk, cylinders vs. gigabytes. This terminology confusion isn’t impossible to overcome, but can engender frustration, particularly during early stages when there’s no common language available.
The groups’ values also often differ. The mainframe community values process, structure, control, and reliability. They’re used to folks having sharply defined areas of responsibility, and believe in exercising careful change control and compatibility testing, with a focus on the strategic applications whose operation cannot be disrupted. They understand that hardware is expensive, and must be used efficiently and completely, and that users and applications must be “good citizens,” sharing the system with others.
The Linux people value entrepreneurial spirit and the flexibility it affords, leading to more experimentation. Since Linux is so young and evolving so fast, Linux folks expect to know a little bit about many things (e.g., networking), and assume that programs will usually be free to interoperate and have source code.
Typical complaints from Linux advocates include:
- “This project is moving so slowly.”
- “This platform is so slow!”
- “How could you not know TCP/IP?” VM folks say things like:
- “These punks know nothing about software development.”
- “There aren’t any measurement tools!”
- “Who do I buy Linux from?”
It’s easy to see how these complaints arise. Neither group is right or wrong and both can learn from each other. It’s important for them to figure out why they’re saying what they’re saying.