We will have this result for the Development Workload soon, as the
result should be a little less than obvious.
Back to Top-Level
This set of experiments is designed to determine how well each of the workloads are able to share the CPU with another process. If a particular workload is able to share a CPU without significant slowdown, it will perhaps be beneficial to schedule many of those non-resource-intensive jobs on the same processor at the same time.
The CPU Workload does not share processors very well. Indeed, since the CPU utilization of each of the scripts was between 98% and 99%, this is not surprising.
On the other hand, the Interactive Workload can easily share the processor, since most of the time it simply isn't doing much at all. The implication is that if we can classify (either statically by a namelist or dynamically by monitoring job history) programs that are resource-non-intensive, we could overload certain machines in the cluster with those jobs, while keeping one job per CPU on other machines. One possible schedule of jobs actively partitions machines into "interactive" or "cpu-intense" groups, and schedules accordingly, similar to the following picture: