gridengine.info

Recently on the mailing list there has been a discussion centering on how to order jobs within a project. For some reason, Daire's reply did not make it into the previous thread list. It is an interesting approach. Daire's method allows groups of jobs within a project to have different levels of priority entitlements in a way that does not interfere with other shares or projects. It also allows users or project leaders to more easily reallocate priorities on the fly, simply by changing the project associated with a task.

Daire writes:

...we decided to abstract gridengine's projects into priority groups
so that you can order jobs within a project by changing the job's project
(qalter -P). So for example if you have 2 projects A and B your 
sharetree might look something like:

ROOT
|-- A (75)
|   |-- A_1 (P) (10)
|   |-- A_2 (P) (1000)
|   |-- A_3 (P) (100000)
|   |-- A_4 (P) (10000000)
|   `-- A_5 (P) (1000000000)
`-- B (25)
   |-- B_1 (P) (10)
   |-- B_2 (P) (1000)
   |-- B_3 (P) (100000)
   |-- B_4 (P) (10000000)
   `-- B_5 (P) (1000000000)

where (P) signifies a gridengine "project" and the numbers in ()'s
are the assigned share values. Now you can move a job within project 
A between the 5 priority levels without effecting project B's share. 
Maybe use the Functional policy to ensure equal shares between users 
in the same priority band? Not sure how much the halflife factor will 
mess with the priority bands but the I'm assuming the large share 
differences between them will override the effect...

Similar discussions occur on this mailing list thread.