← Back to branch summary

~ubuntu-branches/ubuntu/utopic/gridengine/utopic

« back to all changes in this revision

Viewing changes to doc/devel/rfe/priority_class.txt

  • Committer: Bazaar Package Importer
  • Author(s): Mark Hymers
  • Date: 2008-06-25 22:36:13 UTC
  • Revision ID: james.westby@ubuntu.com-20080625223613-tvd9xlhuoct9kyhm
Tags: upstream-6.2~beta2
Import upstream version 6.2~beta2

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/devel/rfe/priority_class.txt
 
1
                            Proposal on Priority Classes (v2)
 
2
 
 
3
                                    Andreas Haas
 
4
 
 
5
1. Objective
 
6
 
 
7
   The purpose of the priority class work package is to provide one consistent
 
8
   priority concept (GE and GEEE) that allows enforcing a strict hierarchy of 
 
9
   job priority classes. Strict means that higher privileged jobs are started 
 
10
   before less privileged jobs if appropriate resources are available.
 
11
 
 
12
2. Current GE priority concept
 
13
 
 
14
   With GE we do have such a priority class concept allowing any user to 
 
15
   assign any priority to a job in the range between -1023 and 0 at submission 
 
16
   time, whereas higher numbers correspond with higher priorities. For assigning 
 
17
   priorities the POSIX switch "-p <priority>" switch is used. The same switch 
 
18
   can be used after job submission for lowering the initial job priority. 
 
19
   The default job class is 0. Priviledged users (i.e. GE operators/managers) 
 
20
   can assign priorities to any job at any time in the range between -1023 and 
 
21
   1024.
 
22
 
 
23
3. Current GEEE priority concept
 
24
 
 
25
   In GEEE the "-p <priority>" switch also exists, but unfortunately it's effect
 
26
   on scheduling is less clear: Depending on the setup of GEEE policies it can 
 
27
   be used to 
 
28
 
 
29
   (1) weight the ticket distribution resulting from GEEE share tree/functional 
 
30
       policy and thus prioritize jobs among each other of the same user or project (?)
 
31
 
 
32
   (2) use the functional policy to implement simple job based strict priority 
 
33
       dispatching similar to GE priority 
 
34
 
 
35
   (3) achieve various combinations of (1) and (2)
 
36
 
 
37
   unfortunately none of these GEEE options satisfies the requirements as fulfilled
 
38
   with GE. The priority concept with (1) is completely different, since it 
 
39
   adresses a different problem apparently. The priority concept with (2) is close to 
 
40
   GE priority concept but this approach has some drawbacks and negative implications
 
41
 
 
42
   - being just an emulation of GE priorty concept certain scheduler optimizations
 
43
     in effect with original GE priority can't take place
 
44
   - since the functional policy is used to implement this priority concept the 
 
45
     functional policy can't be used in conjunction with strict job based priorties 
 
46
   - in opposite to GE the priority of running jobs can't be changed 
 
47
     this is a constrain resulting from certain needs of option (1) 
 
48
   - in opposite to GE this priority concept is not available out-of-the-box,
 
49
     but instead must be implemented explicitly
 
50
 
 
51
   option (3) is a combination of (1) and (2).
 
52
 
 
53
4. Conclusions
 
54
 
 
55
   There is a difference with the priority concepts provided by the two products
 
56
   GE and GEEE. This is of some practice significance as GEEE is considered to be
 
57
   a superset of GE. Thus sites upgrading from GE to GEEE will expect that 
 
58
   any feature they had with GE will available in the same manner with GEEE. This 
 
59
   can be achieved by implementing (2), though by doing so these sites looses
 
60
   functional policy as an important configuration option. Besides the share tree 
 
61
   policy the functional policy is the main reason for sites to decide for GEEE 
 
62
   instead of GE.
 
63
   
 
64
3. WP1: Implement GE priority classes concept as native GEEE feature
 
65
 
 
66
   It is obvious that it is necessary to bring both priority concepts in on line.
 
67
   The GE priority is clear and easy enough to be implemented also in GEEE as a 
 
68
   native feature.
 
69
 
 
70
   In the GEEE scheduler the GE priority must have absolute precedence compared with 
 
71
   the GEEE internal ticket concept. That means jobs with higher GE priority will be 
 
72
   considered first for dispatching regardless of the ticket amount the job gained from 
 
73
   different GEEE policies. Only for jobs with the same GE priority the GEEE tickets 
 
74
   are considered to decide with job is dispatched first.
 
75
 
 
76
   Open questions:
 
77
 
 
78
   1. The decision to be taken is about the GEEE -p submit option. Currently it is 
 
79
      overcharged with two priority concepts. Since both of these priority concepts do 
 
80
      make sense there must be means for the user to differ which priority concept is 
 
81
      meant. One possible solution is to introduce a new GEEE-only option to be used 
 
82
      for controlling GEEE intra-user/intra-project priority concept e.g. 
 
83
      "-ip <priority>". By doing so the "-p <priority>" can be used exclusively for 
 
84
      controlling GE priority also with GEEE.
 
85
 
 
86
   2. Shannon: It should be very easy to replace the use of "job priority" in GEEE 
 
87
      with a concept of "user job tickets" which would simply be the number of 
 
88
      tickets each user associates with his job. The GEEE policies would then 
 
89
      directly use this "user job tickets" value instead of job priority. I would 
 
90
      also prefer using the tickets terminology instead of priority to be consistent
 
91
      with the rest of GEEE.
 
92
 
 
93
5. WP2: Finer-grained control on privileged priority classes
 
94
 
 
95
   Having the GE priority concept available in GEEE provides the basic prerequisite 
 
96
   for further improvements with priority classes. One major deficiency of the GE priority 
 
97
   is that priorities higher than 0 can be only assigned to jobs by privileged users. This 
 
98
   can make frequent manual intervention by GE managers/operator necessary. It is possible 
 
99
   to reduce the amount of cases in which manual interventions by managers/operators becomes 
 
100
   necessary by adding trusted users to the operators ACL. However operators are allowed to 
 
101
   assign *any* priority to their jobs. Also they could be attempted to misuse their operator 
 
102
   privileges in other respect. Thus a more fine grained instruments for controlling access 
 
103
   to high job priorities might be desirable at sites where users are not disciplined enough. 
 
104
 
 
105
   To adress this it is conceivable to provide more fine-grained means for controlling 
 
106
   access to privileged priority classes. With the 'command_line' setting the job class 
 
107
   design provides the administrator with a possibility to assign privileged and 
 
108
   unprivileged priority classes to certain job classes. Since the access to the job class 
 
109
   object is controlled by (x)user_lists job classes can be used for this purpose. 
 
110
  
 
111
   To make the specification complete it is necessary to describe the relation between
 
112
   -p <priority> option specified by the user at command line and the -p <priority> option
 
113
   contained in the JC 'command_line'. A reasonable relation could be to use the JC priority
 
114
   as the default and highest priority allowed when overriding JC priority by the job 
 
115
   priority. 
 
116
   
 
117
   Open questions:
 
118
 
 
119
   1. Further investigation on the relation between JC priority and job priority 
 
120
      is required to figure out what appears to be a reasonable behaviour in case 
 
121
      the JC priority changes.