[comp.os.vms] process priority levels

george@vax2.ccs.cornell.edu (George R Boyce) (06/15/87)

In setting up a resource accounting system, I want to consider the
feature of allowing a user to select a lower process priority, say
3 instead of the default 4, in exchange for being charged a lower
rate. So two questions...

1) Will VMS schedule jobs at two priority levels "fairly" or will the
lower priority jobs never get reasonable response? I know the answer
depends heavily on what job mix we have, so I guess I want to know
if anyone has set up their system to divide their users into two or
more priority classes. (I'm running an 8500 with mostly student
users, a few large SAS or MACSYMA users.)

2) Is their a way to set a process priority limit downward such that
the user can't set it back? The documentation for SET PROCESS/PRIORITY
and SYS$SETPRI seem to be misleading. It suggests that the user can't
set the base priority higher than the existing base priority when in 
fact they can set it back to the former (uaf specified) value. It looks
like I would have to poke around in a system data structure; does anyone
know how to do it? Thanks.

George Boyce, Academic Computing, Cornell University
george@vax2.ccs.cornell.edu (128.84.252.100), george@crnlvax2.bitnet

carl@CITHEX.CALTECH.EDU.UUCP (06/19/87)

 > 1) Will VMS schedule jobs at two priority levels "fairly" or will the lower
 > priority  jobs  never  get  reasonable response?  I know the answer depends
 > heavily on what job mix we have, so I guess I want to know  if  anyone  has
 > set  up  their  system  to  divide  their  users  into two or more priority
 > classes.  (I'm running an 8500 with mostly student users, a few  large  SAS
 > or MACSYMA users.)

What happens is that the computable process with the highest priority get  the
CPU.   VMS  gives  temporary  priority  boosts for processes doing substantial
amounts of I/O, and as I recall, your priority inches  up  VERY  gradually  if
your  process  sits  idle.   For  the  most  part,  however, you can model the
scheduling under VMS as follows:  The processes with the highest base priority
either  run  as  though  each  is alone on the system (in the event they don't
combine to use 100% of the CPU time), or they divide the CPU among themselves.
If the latter, processes with lower base priorities don't run.  If the former,
the processes with the second highest base priority repeat  the  above,  using
whatever fraction of the CPU is left over from the first group, and so on.  On
CITHEX, we tend to use four priorities
   1:   This is for batch jobs that you want to defer payment for more than  a
        month.  Since the job isn't likely to finish for at least a month, you
        don't get billed for the first month's time until the end of the month
        after;
   3:   This if for normal batch jobs:  you typically get a pretty fair amount
        of  CPU  time  in  off hours, and your job might actually do some work
        during business hours, but it won't get  in  the  way  of  interactive
        users (unless of course it allocates both tape drives and continues to
        use both of them once an hour or so for a week and a half).
   5:   This is the interactive job priority level, as well  as  the  priority
        level  for batch jobs you're willing to bet will finish in less than a
        CPU minute.  Nobody has a higher  default  base  priority  than  this.
   7:   This is the priority the backup job runs at when the disk drives start
        making   funny  noises.   I  also  use  it  for  things  like  running
        ANALYZE/DISK/REPAIR on the system disk with the system up and running;
        since  ANAL/DISK/REPA  writelocks  the  volume  (or at least the index
        file) it's dealing with, and since there are things (for example,  the
        accounting  and  error-logging facilities, LOGINOUT, MAIL), and so on)
        that need to write to the system disk, it's easier  on  the  users  to
        give  them  virtually no CPU time for a few minutes than to allow them
        to slowly pile up in various resource wait states.

 > 2) Is their a way to set a process priority limit downward  such  that  the
 > user  can't  set  it  back?  The documentation for SET PROCESS/PRIORITY and
 > SYS$SETPRI seem to be misleading.  It suggests that the user can't set  the
 > base  priority higher than the existing base priority when in fact they can
 > set it back to the former (uaf specified) value.  It  looks  like  I  would
 > have  to poke around in a system data structure; does anyone know how to do
 > it?  Thanks.

Well, one thing you might consider is running an image that:
    1)  Sets its priority down;
    2)  Creates a subprocess, either with $CREPRC or with LIB$SPAWN;
    3)  Waits for the subprocess to die;
    4)  Immediately logs out.
This sort of  thing  works  because,  unless  the  parent  process  explicitly
specifies  a  priority,  the  base  priority  of  a  given job is equal to the
priority at which its parent was running at the time of its creation.

LEICHTER-JERRY@YALE.ARPA.UUCP (06/20/87)

    ...

    1) Will VMS schedule jobs at two priority levels "fairly" or will the
    lower priority jobs never get reasonable response? ...

This isn't easy to answer.  Down at the bottom of it all, at any given moment,
the runnable process with the highest priority will be run.  So in this sense,
the answer is no.  However, there are two (well, three - more below) priori-
ties associated with a job:  Its base priority, and its current priority.
When you set the priority of a process, you are (mainly) manipulating its
base priority, which is the lowest the current priority will ever go.  How-
ever, all but CPU-bound jobs spend most of their time above their base prio-
rity, since various events like I/O completion gain the process a boost.

In principle, a priority 3 CPU-bound job will get no CPU time on any system
with a fair number of users.  In practice, unless the system is very heavily
loaded, you'll tend to see short periods of time when, but chance, a couple
of people are doing compilations (say) when the priority 3 job will be locked
out, but you'll also see long intervals where the priority 3 job chugs away
nicely.  You can get a quick picture of how well those jobs will do by using
MONITOR - any CPU time the priority 3 jobs manage to take from the system will
come mainly from the NULL job.  (That's not quite true, since a priority 3 job
with a priority boost of 3 for an I/O completion will take time from any prio-
rity 4 CPU bound job.)

Just to make life a little more complex, VMS has a special facility, control-
led by the PIXSCAN parameter in SYSGEN, which gives computable processes a
special boost every once in a while.  This mechanism is there to guarantee
that even low priority, CPU-bound processes don't stall indefinately.  (The
problem with allowing them to is that they may be holding a lock on some
resource, like a file, and thus stalling high-priority processes.)
    
    2) Is their a way to set a process priority limit downward such that
    the user can't set it back? The documentation for SET PROCESS/PRIORITY
    and SYS$SETPRI seem to be misleading....

Prior to VMS V4, you could not (without ALTPRI) raise your process priority.
In V4, processes gained a third priority field, the authorized base priority.
You can now lower your priority, or raise it no higher than your authorized
base priority (which is also the base priority LOGINOUT sets for you to begin
with).

Note that a base priority specified for a batch queue overrides any authorized
base priority - you can't SUBMIT a job to a low-priority queue, then raise its
priority to interactive level, either from within the batch job or from an
interactive job.

Either you are looking at old documentation, or there is new documentation out
there that could use some fixup.  Documentation SPR time?

							-- Jerry
-------