Scott_Gavin wrote: > From reading about the Workload Manager... > If you assign a MinCPU percentage to a workgroup, it will gets that % > of the CPU whether they needs it or not. This means that if you have > a workgroup with a 20% MinCPU, but there are no processes in that > workgroup that need the CPU right now, then the CPU will be 20% idle > even if there are 100 other processes that are all desperately want > CPU. Actually, the MINCPU percentage is permissive. That is, if a workgroup cannot use the minimum percentage you assign to it, any other process can use that CPU time. Therefore, a MINCPU percentage will never force the system to go idle unless absolutely no process is ready to use the CPU. It is the MAXCPU percentage cap which is restrictive. If you assign a maximum CPU percentage to a workgroup, that cap will be enforced even if it means that the system must be idle if no other workgroups can use the CPU at that time. In response to Hans Fohrman, who wrote: >> It is important that the sum of all MinCPU never goes over 80 % because >> the OS will then have problem and not have CPU. Scott said: > Because with 80% allocated to various workgroups MinCPU, you only have > one fifth of the system available to MPE and other users :-) Because of the fear of starving system processes, we actually changed the algorithms in the dispatcher so that system processes will override the minimum CPU percent specifications for workgroups. Therefore, there is no danger of assigning minimum CPU percents which have such a large total that system processes will be starved. Scott also wrote: > Workload Manager is similar to mainframe utilites which do the same > kind of stuff. In those environments people are willing to pay 10% > of the CPU's time in overhead to get this kind of control. Fortunately, the extra overhead required to enforce CPU minimums and maximums turned out to be far less than 10%. In our tests the extra Workload Manager overhead was more like 2 percent in the case that both minimums and maximums were being enforced. However, our tests used workloads which were not as complex as an actual production system might have. > If you have a large, complex environment, then Workload Manager looks > like a great tool for getting more control over things. Of course this > comes at some cost in performance, and provides new interesting ways > to shoot yourself in the foot. I think the cost in performance is low. However, I agree about the "new interesting ways to shoot yourself in the foot" part. Steve Cole wrote: > In regards to using the Workload Manager on smaller systems I agree that > it would work. The problem with the Workload Manager on smaller systems > is that the interrupt scheme is not as grandular as it was on previous > releases. This means that the slower the system the less control you > have. While the interrupt scheme was unchanged, we did in fact change the preemption algorithm for the Workload Manager. That means that preemptions are slightly less likely and that more processes run until they block or until they are timesliced. So Steve is quite right that a process may not be able to preempt as quickly, and that might seem to result in less control on a slower system. This change in preemption algorithms is really a part of the dispatcher which is part of all 5.0 push systems; the change is not restricted only to those systems which have the Workload Manager product. Fortunately, toward the very end of the Workload Manager user test period, we were able to improve the CPU percentage controls such that they worked well on systems of all sizes. Before the change, our controls were not as accurate for workgroups which had few processes. After the change, controls were accurate for all workgroups, whether they had one or hundreds of processes. So to me, the determiner of the need for the Workload Manager is not the size or speed of the system; it is the presence or absence of competing populations of processes which need to be controlled. Doug Perry, MPE/iX Lab