sge_priority - Grid Engine job priorities
Grid Engine provides a means for controlling job dispatch and run-time
priorities. The dispatch priority indicates the relative importance of pending
jobs and determines the order in which Grid Engine initially considers
dispatching jobs to queue instances, if the relevant resources are available.
(The actual running order may be influenced may be influenced by other
factors, such as reservations.) The run-time priority determines the CPU
allocation that the operating system assigns to jobs.
A job's dispatch priority (display in the "reduced" output format of
is affected by a number of factors:
- the identity of the submitting user;
- the project under which the job is submitted (or
alternatively, the default project of the submitting user);
- any resources requested by the job;
- the job's submit time;
- the job's initiation deadline time (if specified);
- the -p priority specified for the job (also known as
the POSIX priority " pprio").
The effect of each of these is governed by the overall policy setup, which is
split into three top-level contributions. Each of these is configured through
the parameters weight_priority
. These three parameters control to what degree POSIX
priority, ticket policy, and urgency policy are in effect. To facilitate
interpretation, the raw priorities ("
they are used to calculate job priorities (" prio
Normalization maps each raw urgency/ticket/priority value into a range between
0 and 1.
npprior = normalized(ppri)
nurg = normalized(urg)
ntckts = normalized(tckts)
prio = weight_priority * npprio +
weight_urgency * nurg +
weight_ticket * ntckts
The higher a job's priority value, the earlier it gets dispatched.
The urgency policy defines an urgency value for each job. The urgency value
consists of the resource requirement contribution ( rrcontr
), the waiting
time contribution ( wtcontr
) and the deadline contribution
The resource requirement contribution adds up all resource requirements of a job
into a single numeric value.
= Sum over all(hrr
with an hrr
for each hard resource request. Depending on the resource
type, two different methods are used to determine the value to be used for
here. For numeric type resource requests, the hrr
how much of a resource a job requests (on a per-slot basis for PE jobs) and
how "important" this resource is considered in comparison to other
resources. This is expressed by the formula:
where the resource's urgency value ( rurg
) is as specified under
in the job's assumed_slot_allocation
number of slots supposedly assigned to the job, and the per-slot request is
that which was specified using the -l
option. For string-type requests
the formula is simply
and directly assigns the resource urgency value as specified under
The waiting time contribution represents a weighted waiting time of the jobs
wtcontr = waiting_time *
with the waiting time in seconds and the weight_waiting_time
The deadline contribution has an increasing effect as jobs approach their
deadline initiation time (see the -dl
option in It is defined as the
quotient of the weight_deadline
value from and the (steadily
decreasing) free time in seconds until deadline initiation time
dlcontr = weight_deadline / free_time
or is set to 0 for non-deadline jobs. After the deadline passes, the value is
static and equal to weight_deadline
. The -urg
urgency information for jobs.
The ticket policy unites functional, override and share tree policies in the
ticket value ( tckts
), defined as the sum of the specific ticket values
) for each sub-policy (functional,
tckts = ftckt + otckt + stckt
The ticket policies provide a broad range of means for influencing both job
dispatch and runtime priorities on a per job, per user, per project, and per
department basis. The -ext
option displays ticket information for jobs.
The run-time priority can be dynamically adjusted in order to meet the goals set
with the ticket policy when execution hosts are over-subscribed. Dynamic
run-time priority adjustment can be turned on globally using
in and reprioritize_interval
in If no dynamic
run-time priority adjustment is done at a host level, the priority
specification in is in effect.
Note that urgency and POSIX priorities do not
affect runtime priority.
See for a full statement of rights and permissions.