HP 3000 Manuals HP 3000 Manuals
MPE XL User Interface (Scheduling) Enhancements
by Susan Campbell
Commercial Systems Division
System Managers now have increased flexibility through the following
scheduling enhancements added to this release:
* An additional scheduling property called a boost can be set using the
:TUNE command, which will provide more control over CPU allocation.
* The following two commands have been added to improve system
information handling: the :SHOWPROC command, which will display
process information and the :ALTPROC command, which will dynamically
change process information.
The following describes these enhancements in detail.
THE NEW OSCILLATION BOOST PROPERTY
The boost property can be specified as either decay or oscillate. The
default boost property is decay and it is identical to the current boost
algorithm. Processes begin their transactions at the base of their
scheduling queue (CS, DS, or ES), and decay towards the limit of the
scheduling queue as they consume CPU. Currently (and with the decay boost
property), a process is reset to the base of the queue only when it
completes a Dispatcher transaction. Dispatcher transactions are
considered complete when the process blocks on a terminal read wait, a
parent or child wait, pauses for more than one second, or indicates end
of transaction in a call to the IOWAIT intrinsic.
Longer transactions (transactions that require more CPU to complete) will
therefore decay to the limit of the scheduling queue and remain there.
Given a large amount of activity at the base of a scheduling queue,
processes at the limit of the queue will receive minimal CPU time and
their response times will increase. It is this situation that the
oscillate boost property will address.
When the oscillate boost property is specified via the :TUNE command,
processes are reset to the base of their scheduling queue once their
priority decays to the limit of the queue. Processes will also be
boosted to the base of the queue when they complete their transactions.
A system manager can specify the oscillate boost property for each of the
three user scheduling queues (CS, DS, and ES). The oscillate boost
property allows longer transactions to be reset to the base of the queue
so that they can continue to compete for CPU and maintain good response
time.
Specification of the oscillate boost property will prove helpful if
processes of different transaction lengths are in the same scheduling
queue and the shorter transactions receive excellent response time, while
the longer transactions have longer response times. By :TUNEing the
scheduling queue to have an oscillate boost property, a system manager
can allow the longer transactions to be reset to the base of the
scheduling queue where they can compete with the shorter transactions for
the CPU. Response times should even out since the longer transactions are
no longer being starved at the base of the queue.
The oscillate boost property can also prove useful when scheduling queues
are overlapped to allow batch processes to compete with interactive
process. Typically, when the CS and DS queues are overlapped, it is done
so that the batch processes might compete with the longer transaction
interactive processes. There are two distinct problems that may arise
from this overlap. The longer transaction CS processes may suffer a
great deal when they lose the CPU to the batch jobs at the top of the DS
queue. It is also possible that the batch jobs do not receive much of a
gain from the :TUNEd overlap, because they quickly decay past the region
of overlap and do not receive sufficient CPU. The oscillate boost
property can be used to ensure that the longer transaction CS processes
do not remain at the bottom of the CS queue for an extended period of
time, and can also be used in the DS queue to ensure that the batch jobs
are boosted back into the region of overlap. It may also be necessary to
adjust the quantums of the queues so that the boosting occurs with proper
frequency. The quantums determine how rapidly the priority of a process
decays. The priority of a process will decay more rapidly with a smaller
quantum, and less rapidly with a larger quantum.
CHANGE PROCESS QUEUES DYNAMICALLY
Another scheduling-related change in XL Release 2.1 involves the ability
to dynamically change the scheduling queue in which a process is running.
As with MPE XL releases prior to 2.1, the GETPRIORITY intrinsic in 2.1
provides the ability to programmatically change the scheduling queue of a
process. The new :SHOWPROC and :ALTPROC commands now provide a means of
dynamically displaying and changing process characteristics. The
characteristics that can be changed include the scheduling queue and
priority of a process.
The :SHOWPROC command can be used to display the characteristics of a
process. These characteristics include the scheduling queue and priority
of the process, as well as whether the process is running at a fixed
priority, or is subject to priority decay.
The :RUN command allows you to specify the priority at which the program
is to be run. The priority is specified as BS, CS, DS, ES, or a numeric
priority between 100 and 255. The specification of a queue cannot exceed
MAXPRI for the account or user. If you attempt to specify a priority
higher than the priority permitted for your account or user name, MPE XL
will set the priority to the highest priority below BS. Specifying a
numeric priority value (100-255) will result in the process being fixed
at that priority in the AS scheduling queue. Caution should be used in
assigning fixed priority values (especially in the range 100-152), as
process starvation can result. Remember that the MPE XL Dispatcher is
priority-driven and the highest priority process will receive the CPU.
Fixing the priority of a program at 100 ensures that no one at a priority
greater than 100 will receive the CPU unless the program does not want
the CPU. Many system processes run at priorities in the range of 100 to
150, so a user process running at such a high priority may lock out
system processes, locking up the entire system.
Similar priority-setting features are available with the :ALTPROC
command. Using :ALTPROC, you can specify the priority of a given process
(if you have SM or OP capability). :ALTPROC allows you to change the
priority of a process dynamically. Priority can be specified as BS, CS,
DS, ES, BM, CM, DM, EM, or a numeric priority between 100 and 255. A
process with a priority of BS will be placed at the base of the BS queue
(100) and will remain fixed at that priority. A process with a priority
of CS, DS, or ES will be placed in the appropriate scheduling queue at
the base and will decay to the limit as it consumes CPU. BM, CM, DM, and
EM indicate that the process is to be considered the manager of the
scheduling queue. In this case, the process will be placed at the base
of the indicated scheduling queue and will NOT decay; the priority of the
process will remain fixed at the base of the scheduling queue. The
advantage of using this type of priority specification, versus a numeric
priority, is that the priority of the process will adjust if the
scheduling queue is :TUNEd to new base (a process assigned a numeric
priority will always run at that specific priority). A process which is
assigned a numeric priority will be placed in the AS queue at that
priority value. The specification of a numeric priority requires SM
capability. For users without SM capability (just OP capability), the
priority specified cannot exceed MAXPRI for the user or account. If a
priority greater than MAXPRI is specified, MAXPRI will be used, however,
the priority will never exceed BS. As with the :RUN command, caution
should be used in assigning fixed priority values, or process starvation
can result.
System processes may be modified by the System Manager, but the keyword
;SYSTEM must be used in the command to indicate an awareness that the
process is a system process. In specifying the priority of the process,
users with OP capability can specify BS, CS, DS, or ES. The priority
assigned will not exceed MAXPRI for the account or user. Users with SM
capability can specify priority as BS, CS, DS, ES, BM, CM, DM, EM, or a
numeric priority between 100 and 255. MAXPRI is ignored for System
Managers (SM capability).
Refer to related article in the "Technical Articles" section in this
Communicator for more details regarding the new :SHOWPROC and :ALTPROC
commands, as well as the modified :TUNE and :SHOWQ commands.