>What has been occurring is that during the RMF interval, the 1st service class 
>will consume all available CPU and the 2nd will receive none.
>A short time later, WLM will adjust the dispatching priority and the 2nd 
>service class will receive all available CPU, the first none.

This is an unfortunate artifact of the introduction of the WLM, over 10 years 
ago.
Except for DISCRETIONARY, there is no longer Mean-Time-to-Wait.
This means that for every priority, the lead job will run until it gives up the 
CPU, then the next, the next, and so on.

It can cause problems if you have both CPU-Bound and I/O-Bound jobs at the same 
level.
The I/O job will pop in, consume a little, pop out, and wait behind the CPU job.
If there are a couple of CPU-Bound jobs in the Service Class, your PI's will 
look good, and the WLM will NOT help the I/O-Bound.
The granularity is at the job/priority level, rather than the service class.

I discussed this with IBM, 11 years ago, and even presented in (January 1999) 
as a WLM early experience presentation at CMG Canada.

IBM's solution was to introduce a second period.
My response was:
1. Where? You can't tell when you are going to have problems with CPU vs 
I/O-Bound jobs. And,
2. The limited resource with the WLM is active service classes/periods, so 
let's add more as a half-*ssed solution to an implementation error that IBM 
made over 12 years ago.

They're not going to change it.
-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to