On Sep 19, 2006, at 6:30 AM, Peter Webb, Toronto Transit Commission wrote:
Well, we just had a techy from our local IBM reseller in here yesterday, and he said they could sell us a FLEX based system that would run z/VM 5.2. I'm going to keep my eyes open for a flock of pigs flying past until they put that one on paper, though.
You misunderstand. 64-bit guests run on Flex-ES. Just much more slowly than they need to. We're running 5.1 right now with plans to install 5.2 soon, and it runs it accurately enough. It works, just not very fast when it's doing 64-bit ops, because it's having to simulate 64-bit operations on 32-bit hardware (or, more accurately, a 32-bit OS, even if the *hardware* supports 64-bit operations), which introduces many, many unnecessary host operations. When they quote you the MIPS for the Flex machine, be *sure* to ask whether they're talking about a mostly-31-bit workload or a mostly-64-bit workload. My understanding is that IBM refuses to allow Flex-ES to be licensed on 64-bit host OSes, at least for PWD members, which we are. This may have something to do with levels of Flex-ES (only post-version-6, I think, can exploit a 64-bit host?) and with PWD entitlement as well (so it may be that you *can* go full 64-bit if you are running a production system on your Flex box, but we *aren't*, so I really don't know). Anyway, the current situation means that every time you use a 64-bit instruction, the host CPU has to go and assert a lock around a bunch of 32-bit operations that together implement a 64-bit operation, versus just, you know, running a 64-bit instruction. This makes performance of 64-bit OSes on Flex-ES much worse than it *could* be on the very same hardware. Remember the performance hell of 16-to-32- bit "thunking" back in the 90s on Windows 3.x with win32s (and from Win95 to 16-bit DLLS)? Same basic idea. This is indeed a problem even for development shops: we may not need 6000 MIPS to run our databases, but we *do* indeed do a lot of compilation and, especially under Linux, a lot of encryption computation, because nearly everything protocol-related we're working with uses SSL. We want to be doing this for 64-bit architectures (since SuSE and Red Hat have already dropped 31-bit, and there is obviously confusion within IBM about the status of ongoing 31-bit support (see the Jim Elliot/Boebligen back-and-forth)), and it's really annoying to be kneecapping our zSeries system because IBM won't let us license an already-extant solution that lets us best use the hardware we have. We don't have large, steady, ongoing CPU requirements: we have spiky CPU requirements that do, occasionally, go quite high. Yeah, Hercules would let us get around that for the pure-Linux stuff (although for *that* we could also just cross-compile from Intel if we wanted). It doesn't help for the z/VM-integrated-with-Linux or for the Linux-under-z/VM cases. Hercules is also, as far as I know, slower on the same hardware than Flex-ES; one of its design goals has been portability, and it explicitly trades performance for portability. Point is, it's a nonstarter for a shop that wants to do Linux-on-z/VM and not Linux-in-an-LPAR. We have neither money, space, nor power for a real z9, even a small one, and its associated disks. Flex-ES is clearly the solution that's the right size for what *we're* doing. IBM has stonewalled, as David said, by saying there's "no demand." This is plainly inaccurate: we're demanding it, and I'd be quite surprised if we're the only ones. It may well be that IBM has other reasons for disallowing it. In that case, I'd like them to come clean about what those reasons actually *are* rather than using the flatly-wrong explanation of "no demand." Adam ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
