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.