(Click to open topic with navigation)
Consider the following information associated with calculating the fairshare factor for job X.
Job X
User A
Group B
Account C
QoS D
Class E
User A
Fairshare Target:
50.0
Current Fairshare Usage: 45.0
Group B
Fairshare Target:
[NONE]
Current Fairshare Usage:
65.0
Account C
Fairshare Target:
25.0
Current Fairshare Usage:
35.0
QoS D
Fairshare Target:
10.0+
Current Fairshare Usage:
25.0
Class E
Fairshare Target:
[NONE]
Current Fairshare Usage:
20.0
Priority Weights:
FSWEIGHT
100
FSUSERWEIGHT
10
FSGROUPWEIGHT
20
FSACCOUNTWEIGHT 30
FSQOSWEIGHT
40
FSCLASSWEIGHT
0
In this example, the Fairshare component calculation would be as follows:
Priority += 100 * (
10 * 5 +
20 * 0 +
30 * (-10) +
40 * 0 +
0 * 0)
User A is 5% below his target so fairshare increases the total fairshare factor accordingly. Group B has no target so group fairshare usage is ignored. Account C is above its 10% above its fairshare usage target so this component decreases the job's total fairshare factor. QoS D is 15% over its target but the '+' in the target specification indicates that this is a 'floor' target, only influencing priority when fairshare usage drops below the target value. Thus, the QoS D fairshare usage delta does not influence the fairshare factor.
Fairshare is a great mechanism for influencing job turnaround time via priority to favor a particular distribution of jobs. However, it is important to realize that fairshare can only favor a particular distribution of jobs, it cannot force it. If user X has a fairshare target of 50% of the machine but does not submit enough jobs, no amount of priority favoring will get user X's usage up to 50%.
See the Fairshare Overview for more information.