How many computable processes are there? If there is only one process that wants to use a CPU, then there is a performance advantage to reschedule the kernel thread on the same CPU it was previously executing on, as then it is possible for processor cache to be reused without needing to invalidate it.
Processes can request that they have affinity to a specific set of processors.
Are you having performance problems, or did you just notice this in the output of something like
$ monitor/modes/cpu
If that's where you noticed it, what modes are the time being spent in (user, interrupt, mpsync, etc).
Prior to fastpath support, there was more of a possibility that one processor would be busy in Interrupt mode doing parts of I/O processing, but with 7.3-2 most of the commonly used drivers have the ability to do post processing on any CPU, so that shouldn't be as much of an issue.
If you have more than just a passing interest, there is a complete chapter on Scheduling in the book "OpenVMS Alpha Internals - Scheduling and Process Control Version 7.0" Perhaps you can find a copy at a library or on ebay; it is a Digital Press book that is not part of the standard documentaion, Copyright 1997; not online and may be out of print.
Sentosa, what you are seeing is a Cmos special. He changed the scheduler to load the CPUs from high numbers towards load numbers. The reason for that is that bound kernel processes (interupt handlers, lock manager are often assigned lower cpu numbers.
Nothing to worry about. It might help a little in keeping affinity.
I think VMS will use the first CPU up until it is close to full utilization and then it will start offloading some computation to the second CPU, until it is almost fully utilized, etc., for more CPUs. If you notice MONITOR output, for multiple CPUs, you get more than 100% computing capacity. E.g, for 2 CPUs you get 200%, etc.
I don't think it is necessarily an issue that one CPU is working harder than the other, because I think VMS takes care it it on its own.
Too bad we can not give you -12 points for the prior reply.
Please READ the question and prior replies before wasting your time, and ours, with a speculative, confusing and erroneous answer.
>> I think VMS will use the first CPU up until it is close to full utilization and then it will start offloading some computation to the second CPU
- What does 'first' mean in your country? Low number? - Sentosa indicates the opposite is observed. Have you checked recently? - What is off-loading? Check Jon's solid reply.
There is no such notion as off-loading in OpenVMS. If a process becomes computable then the OpenVMS scheduler will look for a free cpu to schedule it. 'Roughly speaking' It will first look for the last CPU where that process ran, and if that's busy it'll look for the first free cpu starting from high to low. With Hyperthreading enabled, the busyness for a co-thread is also taken into consideration. If all CPUs are busy then priorities are used to decide wheather to pre-empt an other process or not.
"until it is almost fully utilized" It's either busy or it is not. There is no such thing as 'having been busy a lot lately' in the OpenVMS scheduler.
"If you notice MONITOR output, for multiple CPUs, you get more than 100% computing capacity. E.g, for 2 CPUs you get 200%, etc."
Looks like Sentosa knows that, and knows even more, as the per-cpu load is known.
This per-CPU breakdown can be obtained from $MONI MODE/CPU as Jon indicateed (with minor typo), but I particulary like T4 data + TlViz to visualize this.
Hein, I can't help you for wasting so much of your time on my asnwer. But I guess in your country, you have all kinds of time to waste. I did go back and reread the question and see that I answered it wrong. But you didn't answer his question either. Actually, I don't care one way or another. There's clearly enough CPU power to go around. And besides, MONITOR is just a snapshot.
A suggestion. While OpenVMS is, by default, case-blind, perhaps the post in this thread concerning scheduling genesis (and it exegesis) is more appropriately "CMos". The semi-conductor technology is "CMOS".
Maybe this is no longer the case, but to my understanding, the thing that drove this situation is the number of jobs in the COM queue that were eligible to run on a particular CPU.
Without affinity settings, if the scheduler module runs and finds an idle CPU at the same time that it has a COM process, it changes it from COM to CUR on the idle CPU. Then (because a schedule event has just occurred), it runs AGAIN. If there is still an idle CPU and a COM process, the same transition occurs but for the next idle CPU and so on.
I can look at a SHOW SYSTEM and see the CPU associated with every CUR process, and I sometimes do see more than one CUR (counting myself) on my four-CPU Alphas.
To see what is happening as described, I believe you would have to have a very thin COM queue.
