Come to think of it, I think an IFL is a single zSeries core. z/VM can fake it, though that's "overcommitting" the CPU resource.
Despite my NOT looking at the zSeries Principles of Operation I somehow doubt the zSeries has hyperthreading... as the z/VM OS would be dispatch threads. On the Intel CPUs, Linux is pretty smart in making a hyperthreaded CPU "double" the number of dispatchable resources... for each "core" built into the die. So I'm going to boast about my ignorance; I don't think an IFL CP implies multiple "cores" handling the zSeries instruction set. -soup On Wed, Nov 8, 2017 at 7:35 PM, Alan Altmark <alan_altm...@us.ibm.com> wrote: > On Wednesday, 11/08/2017 at 09:55 GMT, Philipp Kern <p...@philkern.de> > wrote: > > I thought unused CP capacity was literally costing OpEx whereas IFLs > > would be CapEx? If it's both OpEx, then yes, agreed. (And I suppose > > originally there might have been deals about giving some IFLs with > > upgrades? ;-) > > Eh? Processors are processors: CP, IFL, zIIP, CF, whatever. > > - Processor purchase: CapEx > - Processor rental: OpEx > - Processor recurring maintenance: OpEx > - Software one-time-charge (z/VM): CapEx > - OTC software recurring maintenance: OpEx > - Monthly software charges (z/OS): OpEx > > This is why z/OS usage is so carefully monitored and controlled. You can > budget a large spike for a capital purchase, but uncontrolled monthly > software charges create monthly budget crises. > > By adding capacity, you increase the software costs. > > If your software is priced per CPU (z/VM, Linux), then you will know that > when you add a CPU, you also need to add money for licenses, and you know > exactly what your maintenance bill will be. Over-configured machines > typically mean over-paying for your software and wasting money on > maintenance charges on something you're not using. > > If your software is priced based on capacity rather than the number of > CPUs, as z/OS is, then you typically look at subcapacity billing models > that let you configure your hardware for spikes, but hold the rolling > 4-hour average to a lower level. There are mechanisms in z/OS that can be > configured to thwart it's natural tendency (common to all OSes) to run as > much as it can as fast as it using all the resources at its disposal. > > No rule applies 100% of the time (except this one), so there can be > variations and combinations. > > Alan Altmark > > Senior Managing z/VM and Linux Consultant > IBM Systems Lab Services > IBM Z Delivery Practice > ibm.com/systems/services/labservices > office: 607.429.3323 > mobile; 607.321.7556 > alan_altm...@us.ibm.com > IBM Endicott > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- John R. Campbell Speaker to Machines souperb at gmail dot com MacOS X proved it was easier to make Unix user-friendly than to fix Windows "It doesn't matter how well-crafted a system is to eliminate errors; Regardless of any and all checks and balances in place, all systems will fail because, somewhere, there is meat in the loop." - me ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
