General Purpose processors are built to be capable of reaching speed 'x', but depending on what System z you ordered, may be capped at a lower speed - and thus priced at a lower price. Think: sub-capacity
This makes upgrades very fast and easy for IBM and customers - after an upgrade (within that model range) has been agreed to, the CE goes into the machine room and enters the appropriate mystical incantations and the processor suddenly runs at the faster, agreed on speed. I don't recall if any outage is even required. It also means that IBM does not have to build, test, and maintain so many different chips - just one high-speed chip per model group that can be knee-capped and upgraded though micro-code as required. IFLs always run at the model group's maximum speed 'x'. That's part of the incentive for new Linux for System z customers, they get the full speed the chip at a much lower cost than if it were running as a General Processor, and IFL upgrades come along for "free" when the box is upgraded while you pay for General Purpose CPU engine upgrades. If Linux work is included on General Processor CPU, they will consume General Processor CPU cycles. If that Linux work causes an upgrade of the General Processor, then some software licenses may require an upgrade fee related to the General Processor upgrade. If the Linux work is confined to IFL's, when they need more resources you add another (lower-priced, but full-speed) IFL, which does not affect General Processor product licensing charges. It is likely that the IFL engine is already aboard your present System z, too - just not turned on. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Schuh, Richard" <[email protected]> Sent by: "The IBM z/VM Operating System" <[email protected]> 07/14/2010 10:38 AM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: question to mixed CP an IFL in one LPAR Do you not control whether a Linux guest is dispatched on IFLs or regular CPUs via the directory? If a guest can only run on IFLs and not regular CPUs because of this, do the license fees increase if a Linux workload is melded in with a regular workload instead of running it in a separate LPAR? When did the IFL become faster than a regular CPU? Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[email protected]] On Behalf Of Dave Jones > Sent: Wednesday, July 14, 2010 8:06 AM > To: [email protected] > Subject: Re: question to mixed CP an IFL in one LPAR > > Franz, the IBM-er is right, you can mix CP and IFL in a > single LPAR with either z/VM 5.4 or 6.1......if you are > running 6.1, your system must be a z10. > > However, even if it is technically possible to mix engines, I > generally recommend that you limit your Linux LPARs to IFLs > only. It guarantees that all work in the LPAR will be > dispatched on the faster IFL engines, and may have financial > implications with respect to software licensing charges. > > On 07/14/2010 02:34 AM, Franz Josef Pohlen wrote: > > Hello listers, > > > > an IBMer has told me that a mixture of CPs and IFLs in one LPAR are > > supported on z10 not only with z/VM 6 but also with zVM > 5.4. Is this > > correct? I thought that for those environments you must have z/VM 6. > > > > > > -- > Dave Jones > V/Soft > www.vsoft-software.com > Houston, TX > 281.578.7544 > The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
