SGE_PRIORITY(5)

SGE_PRIORITY(5) 💖 Grid Engine File Formats

okay bestie, this is sge_priority from the Grid Engine manual — it's the whole lore on how Grid Engine decides who goes first. pull up a chair 🫶

---

✨ NAME ✨

sge_priority — Grid Engine job priorities 👑

---

🌸 DESCRIPTION 🌸

so Grid Engine literally gives you a way to control two whole flavors of priority: job dispatch and run-time. let's break it down because they are NOT the same thing, iykyk.

The dispatch priority is basically the vibe check for pending jobs — it says how relatively important each waiting job is, and it decides the order in which Grid Engine initially considers dispatching jobs to queue instances, assuming the relevant resources are actually available. 🎯 (and fr fr, the actual running order may be influenced by other factors, like reservations — so don't come for me if it's not exact.)

The run-time priority, on the other hand, is what determines the CPU allocation that the operating system hands to jobs. that's the one the OS sees. 💅

---

🦋 JOBS DISPATCH PRIORITY 🦋

A job's dispatch priority — which gets displayed in the "reduced" output format of qstat(1) — is affected by a whole lil' roster 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 splits into three top-level contributions. Each one is configured through the sched_conf(5) parameters weight_priority, weight_ticket and weight_urgency. These three control to what degree POSIX priority, ticket policy, and urgency policy are in effect. To make it easier to interpret, the raw priorities (tckts / urg / ppri) get normalized (ntckts / nurg / npprior) before they're 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. periodt. 🔥

💜 the urgency policy

The urgency policy defines an urgency value for each job. The urgency value

urg =  rrcontr + wtcontr + dlcontr

consists of the resource requirement contribution (rrcontr), the waiting time contribution (wtcontr) and the deadline contribution (dlcontr). three little icons working together ✨

The resource requirement contribution adds up all resource requirements of a job into a single numeric value.

rrcontr = 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 hrr here.

• For numeric type resource requests, the hrr represents 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. Expressed as:

hrr = rurg * assumed_slot_allocation * request

where the resource's urgency value (rurg) is as specified under urgency in complex(5), the job's assumed_slot_allocation represents the number of slots supposedly assigned to the job, and the per-slot request is the one you specified with the -l qsub(1) option.

• For string-type requests the formula is simply

hrr = rurg

and it directly assigns the resource urgency value as specified under urgency in complex(5).

The waiting time contribution represents a weighted waiting time of the jobs:

wtcontr = waiting_time * weight_waiting_time

with the waiting time in seconds and the weight_waiting_time value as specified in sched_conf(5).

The deadline contribution hits harder and harder as jobs approach their deadline initiation time (see the -dl option in qsub(1)). It's defined as the quotient of the weight_deadline value from sched_conf(5) and the (steadily decreasing) free time in seconds until deadline initiation time:

dlcontr = weight_deadline / free_time

…or it's set to 0 for non-deadline jobs. After the deadline passes, the value is static and equal to weight_deadline. The qstat(1) -urg option displays urgency information for jobs. 🕐

🎟️ the ticket policy

The ticket policy unites functional, override and share tree policies in the ticket value (tckts), defined as the sum of the specific ticket values (ftckt / otckt / stckt) for each sub-policy (functional, override, share):

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 qstat(1) -ext option displays ticket information for jobs. 👑

---

🧚 JOB RUN-TIME PRIORITY 🧚

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 reprioritize in sge_conf(5) and reprioritize_interval in sched_conf(5). If no dynamic run-time priority adjustment is done at a host level, the priority specification in queue_conf(5) is in effect.

⚠️ heads up bestie: note that urgency and POSIX priorities do not affect runtime priority. not even a little. 💀

---

🎀 SEE ALSO 🎀

sge_intro(1), complex(5), qstat(1), qsub(1), sched_conf(5), sge_conf(5)

---

🌈 COPYRIGHT 🌈

See sge_intro(1) for a full statement of rights and permissions.

---

and that's the whole thing, gorgeous 💖 this page is from SGE 8.1.3pre, dated 2007-01-05 — so yeah, vintage but iconic, like a thrifted jacket that actually slays. go forth and get dispatched first 🌟🦋💅