~ubuntu-branches/ubuntu/vivid/slurm-llnl/vivid

<!--#include virtual="header.txt"-->

 

<h1>Multifactor Priority Plugin</h1>

 

<b>Note:</b> This document describes features added to SLURM version 2.0.

 

<h2>Contents</h2>

<UL>

<LI> <a href=#intro>Introduction</a>

<LI> <a href=#mfjppintro>Multi-factor Job Priority Plugin</a>

<LI> <a href=#general>Job Priority Factors In General</a>

<LI> <a href=#age>Age Factor</a>

<LI> <a href=#jobsize>Job Size Factor</a>

<LI> <a href=#partition>Partition Factor</a>

<LI> <a href=#qos>Quality of Service (QOS) Factor</a>

<LI> <a href=#fairshare>Fair-share Factor</a>

<LI> <a href=#sprio>The <i>sprio</i> utility</a>

<LI> <a href=#config>Configuration</a>

<LI> <a href=#configexample>Configuration Example</a>

</UL>

 

<!-------------------------------------------------------------------------->

<a name=intro>

<h2>Introduction</h2></a>

 

<P> By default, SLURM assigns job priority on a First In, First Out (FIFO) basis.  FIFO scheduling should be configured when SLURM is controlled by an external scheduler.</P>

 

<P> The <i>PriorityType</i> parameter in the slurm.conf file selects the priority plugin.  The default value for this variable is "priority/basic" which enables simple FIFO scheduling. (See <a href="#config">Configuration</a> below)</P>

 

<P> SLURM version 2.0 includes the Multi-factor Job Priority plugin.  This plugin provides a very versatile facility for ordering the queue of jobs waiting to be scheduled.</P>

 

<!-------------------------------------------------------------------------->

<a name=mfjppintro>

<h2>Multi-factor 'Factors'</h2></a>

 

<P> There are five factors in the Multi-factor Job Priority plugin that influence job priority:</P>

 

<DL>

<DT> Age

<DD> the length of time a job has been waiting in the queue, eligible to be scheduled

<DT> Fair-share

<DD> the difference between the portion of the computing resource that has been promised and the amount of resources that has been consumed

<DT> Job size

<DD> the number of nodes a job is allocated

<DT> Partition

<DD> a factor associated with each node partition

<DT> QOS

<DD> a factor associated with each Quality Of Service (Still under Development)

</DL>

 

<P> Additionally, a weight can be assigned to each of the above

  factors.  This provides the ability to enact a policy that blends a

  combination of any of the above factors in any portion desired.  For

  example, a site could configure fair-share to be the dominant factor

  (say 70%), set the job size and the age factors to each contribute

  15%, and set the partition and QOS influences to zero.</P>

 

<!-------------------------------------------------------------------------->

<a name=general>

<h2>Job Priority Factors In General</h2></a>

 

<P> The job's priority at any given time will be a weighted sum of all the factors that have been enabled in the slurm.conf file.  Job priority can be expressed as:</P>

<PRE>

Job_priority =

        (age_weight) * (age_factor) +

        (fair-share_weight) * (fair-share_factor) +

        (job_size_weight) * (job_size_factor) +

        (partition_weight) * (partition_factor) +

        (QOS_weight) * (QOS_factor)

</PRE>

 

<P> All of the factors in this formula are floating point numbers that

  range from 0.0 to 1.0.  The weights are unsigned, 32 bit integers.

  The job's priority is an integer that ranges between 0 and

  4294967295.  The higher the number,  the higher the job will be

  positioned in the queue, and the sooner the job will be scheduled.

  A job's priority, and hence its order in the queue, will vary over

  time.  For example, the longer a job sits in the queue, the higher

  its priority will grow when the age_weight is non-zero.</P>

 

<P> <b>IMPORTANT:</b> The weight values should be high enough to get a

  good set of significant digits since all the factors are floating

  point numbers from 0.0 to 1.0. For example, one job could have a

  fair-share factor of .59534 and another job could have a fair-share

  factor of .50002.  If the fair-share weight is only set to 10, both

  jobs would have the same fair-share priority. Therefore, set the

  weights high enough to avoid this scenario, starting around 1000 or

  so for those factors you want to make predominant.</P>

 

<!-------------------------------------------------------------------------->

<a name=age>

<h2>Age Factor</h2></a>

 

<P> The age factor represents the length of time a job has been sitting in the queue and eligible to run.  In general, the longer a job waits in the queue, the larger its age factor grows.  However, the age factor for a dependent job will not change while it waits for the job it depends on to complete.  Also, the age factor will not change when scheduling is withheld for a job whose node or time limits exceed the cluster's current limits.</P>

 

<P> At some configurable length of time (<i>PriorityMaxAge</i>), the age factor will max out to 1.0.</P>

 

<!-------------------------------------------------------------------------->

<a name=jobsize>

<h2>Job Size Factor</h2></a>

 

<P> The job size factor correlates to the number of nodes the job has requested.  This factor can be configured to favor larger jobs or smaller jobs based on the state of the <i>PriorityFavorSmall</i> boolean in the slurm.conf file.  When <i>PriorityFavorSmall</i> is NO, the larger the job, the greater its job size factor will be.  A job that requests all the nodes on the machine will get a job size factor of 1.0.  When the <i>PriorityFavorSmall</i> Boolean is YES, the single node job will receive the 1.0 job size factor.</P>

 

<!-------------------------------------------------------------------------->

<a name=partition>

<h2>Partition Factor</h2></a>

 

<P> Each node partition can be assigned a factor from 0.0 to 1.0.  The higher the number, the greater the job priority will be for jobs that are slated to run in this partition.</P>

 

<!-------------------------------------------------------------------------->

<a name=qos>

<h2>Quality of Service (QOS) Factor</h2></a>

 

<P> Each QOS can be assigned a factor from 0.0 to 1.0.  The higher the

  number, the greater the job priority will be for jobs that request

  this QOS. (Still under Development)</P>

 

<!-------------------------------------------------------------------------->

<a name=fairshare>

<h2>Fair-share Factor</h2></a>

 

<b>Note:</b> Computing the fair-share factor requires the installation

and operation of the <a href="accounting.html">SLURM Accounting

Database</a> to provide the assigned shares and the consumed,

computing resources described below.

 

<P> The fair-share component to a job's priority influences the order in which a user's queued jobs are scheduled to run based on the portion of the computing resources they have been allocated and the resources their jobs have already consumed.  The fair-share factor does not involve a fixed allotment, whereby a user's access to a machine is cut off once that allotment is reached.</P>

 

<P> Instead, the fair-share factor serves to prioritize queued jobs such that those jobs charging accounts that are under-serviced are scheduled first, while jobs charging accounts that are over-serviced are scheduled when the machine would otherwise go idle.</P>

 

<P> SLURM's fair-share factor is a floating point number between 0.0 and 1.0 that reflects the shares of a computing resource that a user has been allocated and the amount of computing resources the user's jobs have consumed.  The higher the value, the higher is the placement in the queue of jobs waiting to be scheduled.</P>

 

<P> The computing resource is currently defined to be computing cycles delivered by a machine in the units of processor*seconds.  Future versions of the fair-share factor may additionally include a memory integral component.</P>

 

<h3> Normalized Shares</h3>

 

<P> The fair-share hierarchy represents the portions of the computing resource that have been allocated to multiple projects.  These allocations are assigned to an account.  There can be multiple levels of allocations made as allocations of a given account are further divided to sub-accounts:</P>

 

<div class="figure">

  <img src=AllocationPies.gif width=400 ><BR>

  Figure 1. Machine Allocation

</div>

 

<P> The chart above shows the resources of the machine allocated to four accounts, A, B, C and D.  Furthermore, account A's shares are further allocated to sub accounts, A1 through A4.  Users are granted permission (through sacctmgr) to submit jobs against specific accounts.  If there are 10 users given equal shares in Account A3, they will each be allocated 1% of the machine.</P>

 

<P> A user's normalized shares is simply</P>

 

<PRE>

S =     (S_user / S_sibblings) *

        (S_account / S_{sibbling-accounts}) *

        (S_parent / S_{parent-sibblings}) * ...

</PRE>

 

Where:

 

<DL>

<DT> S

<DD> is the user's normalized share, between zero and one

<DT> S_user

<DD> are the number of shares of the account allocated to the user

<DT> S_sibblings

<DD> are the total number of shares allocated to all users permitted to charge the account (including S_user)

<DT> S_account

<DD> are the number of shares of the parent account allocated to the account

<DT> S_{sibbling-accounts}

<DD> are the total number of shares allocated to all sub-accounts of the parent account

<DT> S_parent

<DD> are the number of shares of the grandparent account allocated to the parent

<DT> S_{parent-sibblings}

<DD> are the total number of shares allocated to all sub-accounts of the grandparent account

</DL>

 

<h3> Normalized Usage</h3>

 

<P> The total number of processor*seconds that a machine is able to deliver over a fixed time period (for example, a day) is a fixed quantity.  The processor*seconds allocated to every job are tracked and saved to the SLURM database in real-time.  If one only considered usage over a fixed time period, then calculating a user's normalized usage would be a simple quotient:</P>

 

<PRE>

        U_N = U_user / R_available

</PRE>

 

Where:

 

<DL>

<DT> U_N

<DD> is normalized usage, between zero and one

<DT> U_user

<DD> is the processor*seconds consumed by all of a user's jobs in a given account for over a fixed time period

<DT> R_available

<DD> is the total number of processor*seconds a machine can deliver during that same time period

</DL>

 

<P> However, significant real-world usage quantities span multiple time periods.  Rather than treating usage over a number of weeks or months with equal importance, SLURM's fair-share priority calculation places more importance on the most recent resource usage and less importance on usage from the distant past.</P>

 

<P> The SLURM usage metric is based off a half-life formula that favors the most recent usage statistics.  Usage statistics from the past decrease in importance based on a single decay factor, D:</P>

 

<PRE>

        U_H = U_{current_period} +

             ( D * U_{last_period}) + (D * D * U_period-2) + ...

</PRE>

 

Where:

 

<DL>

<DT> U_H

<DD> is the historical usage subject to the half-life decay

<DT> U_{current_period}

<DD> is the usage charged over the current measurement period

<DT> U_{last_period}

<DD> is the usage charged over the last measurement period

<DT> U_period-2

<DD> is the usage charged over the second last measurement period

<DT> D

<DD> is a decay factor between zero and one that delivers the

  half-life decay based off the <i>PriorityDecayHalfLife</i> setting

  in the slurm.conf file.  Without accruing additional usage, a user's

  U_H usage will decay to 1/2 value after a time period

  of <i>PriorityDecayHalfLife</i> seconds.

</DL>

 

<P> In practice, the <i>PriorityDecayHalfLife</i> could be a matter of

  seconds or days as appropriate for each site.  The measurement

  period is nominally 5 minutes.  The decay factor, D, is assigned the

  value that will achieve the half-life decay rate specified by

  the <i>PriorityDecayHalfLife</i> parameter.</P> 

 

<P> The historical resources a machine has available could be similarly aggregated with the same decay factor:</P>

 

<PRE>

        R_H = R_{current_period} +

            ( D * R_{last_period}) + (D * D * R_period-2) + ...

</PRE>

 

<P> However, A simpler formula is:</P>

 

<PRE>

        R_H = num_procs * half_life * 2

</PRE>

 

Where:

 

<DL>

<DT> R_H

<DD> is the historical resources available subject to the same half-life decay as the usage formula.

<DT> num_procs</sub>

<DD> is the total number of processors in the cluster

<DT> half_life</sub>

<DD> is the configured half-life(<i>PriorityDecayHalfLife</i>)

</DL>

 

<P> A user's normalized usage that spans multiple time periods then becomes:</P>

 

<PRE>

        U = U_H / R_H

</PRE>

 

 

<h3>Simplified Fair-Share Formula</h3>

 

<P> The simplified formula for calculating the fair-share factor for usage that spans multiple time periods and subject to a half-life decay is:</P>

 

<PRE>

        F = (S - U + 1) / 2

</PRE>

 

Where:

 

<DL compact>

<DT> F

<DD> is the fair-share factor

<DT> S

<DD> is the normalized shares

<DT> U

<DD> is the normalized usage factoring in half-life decay

</DL>

 

<P> The fair-share factor will therefore range from zero to one, where one represents the highest priority for a job.  A fair-share factor of 0.5 indicates that the user's jobs have used exactly the portion of the machine that they have been allocated.  A fair-share factor of above 0.5 indicates that the user's jobs have consumed less than their allocated share while a fair-share factor below 0.5 indicates that the user's jobs have consumed more than their allocated share of the computing resources.</P>

 

<h3>The Fair-share Factor Under An Account Hierarchy</h3>

 

<P> The method described above presents a system whereby the priority of a user's job is calculated based on the portion of the machine allocated to the user and the historical usage of all the jobs run by that user under a specific account.</P>

 

<P> Another layer of "fairness" is necessary however, one that factors in the usage of other users drawing from the same account.  This allows a job's fair-share factor to be influenced by the computing resources delivered to jobs of other users drawing from the same account.</P>

 

<P> If there are two members of a given account, and if one of those users has run many jobs under that account, the job priority of a job submitted by the user who has not run any jobs will be negatively affected.  This ensures that the combined usage charged to an account matches the portion of the machine that is allocated to that account.</P>

 

<P> In the example below, when user 3 submits their first job using account C, they will want their job's priority to reflect all the resources delivered to account B.  They do not care that user 1 has been using up a significant portion of the cycles allocated to account B and user 2 has yet to run a job out of account B.  If user 2 submits a job using account B and user 3 submits a job using account C, user 3 expects their job to be scheduled before the job from user 2.</P>

 

<div class="figure">

  <img src=UsagePies.gif width=400 ><BR>

  Figure 2. Usage Example

</div>

 

<h3>The SLURM Fair-Share Formula</h3>

 

<P> The SLURM fair-share formula has been designed to provide fair scheduling to users based on the allocation and usage of every account.</P>

 

<P> The actual formula used is a refinement of the formula presented above:</P>

 

<PRE>

        F = (S - U_E + 1) / 2

</PRE>

 

<P> The difference is that the usage term is effective usage, which is defined as:</P>

 

<PRE>

        U_E = U_Achild +

                  ((U_Eparent - U_Achild) * S_child/S_{all_siblings})

</PRE>

 

Where:

 

<DL>

<DT> U_E

<DD> is the effective usage of the child user or child account

<DT> U_Achild

<DD> is the actual usage of the child user or child account

<DT> U_Eparent

<DD> is the effective usage of the parent account

<DT> S_child

<DD> is the shares allocated to the child user or child account

<DT> S_{all_siblings}

<DD> is the shares allocated to all the children of the parent account

</DL>

 

<P> This formula only applies with the second tier of accounts below root.  For the tier of accounts just under root, their effective usage equals their actual usage.</P>

 

<P> Because the formula for effective usage includes a term of the effective usage of the parent, the calculation for each account in the tree must start at the second tier of accounts and proceed downward:  to the children accounts, then grandchildren, etc.  The effective usage of the users will be the last to be calculated.</P>

 

<P> Plugging in the effective usage into the fair-share formula above yields a fair-share factor that reflects the aggregated usage charged to each of the accounts in the fair-share hierarchy.</P>

 

<h3>Example</h3>

 

<P> The following example demonstrates the effective usage calculations and resultant fair-share factors. (See Figure 3 below.)</P>

 

<P> The machine's computing resources are allocated to accounts A and D with 40 and 60 shares respectively.  Account A is further divided into two children accounts, B with 30 shares and C with 10 shares.  Account D is further divided into two children accounts, E with 25 shares and F with 35 shares.</P>

 

<P> Note:  the shares at any given tier in the Account hierarchy do not need to total up to 100 shares.  This example shows them totaling up to 100 to make the arithmetic easier to follow in your head.</P>

 

<P> User 1 is granted permission to submit jobs against the B account.  Users 2 and 3 are granted one share each in the C account.  User 4 is the sole member of the E account and User 5 is the sole member of the F account.</P>

 

<P> Note:  accounts A and D do not have any user members in this example, though users could have been assigned.</P>

 

<P> The shares assigned to each account make it easy to determine normalized shares of the machine's complete resources.  Account A has .4 normalized shares, B has .3 normalized shares, etc.  Users who are sole members of an account have the same number of normalized shares as the account.  (E.g., User 1 has .3 normalized shares).  Users who share accounts have a portion of the normalized shares based on their shares.  For example, if user 2 had been allocated 4 shares instead of 1, user 2 would have had .08 normalized shares.  With users 2 and 3 each holding 1 share, they each have a normalized share of  0.05.</P>

 

<P> Users 1, 2, and 4 have run jobs that have consumed the machine's computing resources.  User 1's actual usage is 0.2 of the machine; user 2 is 0.25,  and user 4 is 0.25.</P>

 

<P> The actual usage charged to each account is represented by the solid arrows.  The actual usage charged to each account is summed as one goes up the tree.  Account C's usage is the sum of the usage of Users 2 and 3; account A's actual usage is the sum of its children, accounts B and C.</P>

 

<div class="figure">

  <img src=ExampleUsage.gif width=400 ><BR>

  Figure 3. Fair-share Example

</div>

 

<UL>

<LI> User 1 normalized share: 0.3

<LI> User 2 normalized share: 0.05

<LI> User 3 normalized share: 0.05

<LI> User 4 normalized share: 0.25

<LI> User 5 normalized share: 0.35

</UL>

 

<P> As stated above, the effective usage is computed from the formula:</P>

 

<PRE>

        U_E = U_Achild +

                  ((U_Eparent - U_Achild) * S_child/S_{all_siblings})

</PRE>

 

<P> The effective usage for all accounts at the first tier under the root allocation is always equal to the actual usage:</P>

 

Account A's effective usage is therefore equal to .45.  Account D's effective usage is equal to .25.

 

<UL>

<LI> Account B effective usage: 0.2 + ((0.45 - 0.2) * 30 / 40) = 0.3875

<LI> Account C effective usage: 0.25 + ((0.45 - 0.25) * 10 / 40) = 0.3

<LI> Account E effective usage: 0.25 + ((0.25 - 0.25) * 25 / 60) = 0.25

<LI> Account F effective usage: 0.0 + ((0.25 - 0.0) * 35 / 60) = 0.1458

</UL>

 

<P> The effective usage of each user is calculated using the same formula:</P>

 

<UL>

<LI> User 1 effective usage: 0.2 + ((0.3875 - 0.2) * 1 / 1) = 0.3875

<LI> User 2 effective usage: 0.25 + ((0.3 - 0.25) * 1 / 2) =  0.275

<LI> User 3 effective usage: 0.0 + ((0.3 - 0.0) * 1 / 2) =  0.15

<LI> User 4 effective usage: 0.25 + ((0.25 - 0.25) * 1 / 1) = 0.25

<LI> User 5 effective usage: 0.0 + ((.1458 - 0.0) * 1 / 1) =  0.1458

</UL>

 

<P> Using the SLURM fair-share formula,</P>

 

<PRE>

        F = (S - U_E + 1) / 2

</PRE>

 

<P> the fair-share factor for each user is:</P>

 

<UL>

<LI> User 1 fair-share factor: (.3 - .3875 + 1) / 2 =  0.45625

<LI> User 2 fair-share factor: (.05 - .275 + 1) / 2 =  0.3875

<LI> User 3 fair-share factor: (.05 - .15 + 1) / 2 =  0.45

<LI> User 4 fair-share factor: (.25 - .25 + 1) / 2 =  0.5

<LI> User 5 fair-share factor: (.35 - .1458 + 1) / 2 =  0.6021

</UL>

 

<P> From this example, once can see that users 1,2, and 3 are over-serviced while user 5 is under-serviced.  Even though user 3 has yet to submit a job, his/her fair-share factor is negatively influenced by the jobs users 1 and 2 have run.</P>

 

<P> Based on the fair-share factor alone, if all 5 users were to submit a job charging their respective accounts, user 5's job would be granted the highest scheduling priority.</P>

 

<!-------------------------------------------------------------------------->

<a name=sprio>

<h2>The <i>sprio</i> utility</h2></a>

 

<P> The <i>sprio</i> command provides a summary of the five factors

that comprise each job's scheduling priority.  While <i>squeue</i> has

format options (%p and %Q) that display a job's composite priority,

sprio can be used to display a breakdown of the priority components

for each job.  In addition, the <i>sprio -w</i> option displays the

weights (PriorityWeightAge, PriorityWeightFairshare, etc.) for each

factor as it is currently configured.</P>

 

<!-------------------------------------------------------------------------->

<a name=config>

<h2>Configuration</h2></a>

 

<P> The following slurm.conf (SLURM_CONFIG_FILE) parameters are used to configure the Multi-factor Job Priority Plugin.  See slurm.conf(5) man page for more details.</P>

 

<DL>

<DT> PriorityType

<DD> Set this value to "priority/multifactor" to enable the Multi-factor Job Priority Plugin.  The default value for this variable is "priority/basic" which enables simple FIFO scheduling.

<DT> PriorityDecayHalfLife

<DD> This determines the contribution of historical usage on the

  composite usage value.  The higher the number, the longer past usage

  affects fair-share.  If set to 0 no decay will be applied.  This is helpful if

  you want to enforce hard time limits per association.  If set to 0

  PriorityUsageResetPeriod must be set to some interval. 

  The unit is a time string (i.e. min, hr:min:00, days-hr:min:00, or

  days-hr).  The default value is 7-0 (7 days). 

<DT> PriorityUsageResetPeriod

<DD> At this interval the usage of associations will be reset to 0.

  This is used if you want to enforce hard limits of time usage per

  association.  If PriorityDecayHalfLife is set to be 0 no decay will

  happen and this is the only way to reset the usage accumulated by

  running jobs.  By default this is turned off and it is advised to

  use the PriorityDecayHalfLife option to avoid not having anything

  running on your cluster, but if your schema is set up to only allow

  certain amounts of time on your system this is the way to do it.

  The unit is a time string (i.e. min, hr:min:00, days-hr:min:00, or

  days-hr). The default value is not set (turned off). 

 

<DT> PriorityFavorSmall

<DD> A boolean that sets the polarity of the job size factor.  The

  default setting is NO which results in larger node sizes having a

  larger job size factor.  Setting this parameter to YES means that

  the smaller the job, the greater the job size factor will be.

<DT> PriorityMaxAge

<DD> Specifies the queue wait time at which the age factor maxes out.

  The unit is a time string (i.e. min, hr:min:00, days-hr:min:00, or

  days-hr).  The default value is 7-0 (7 days). 

<DT> PriorityWeightAge

<DD> An unsigned integer that scales the contribution of the age factor.

<DT> PriorityWeightFairshare

<DD> An unsigned integer that scales the contribution of the fair-share factor.

<DT> PriorityWeightJobSize

<DD> An unsigned integer that scales the contribution of the job size factor.

<DT> PriorityWeightPartition

<DD> An unsigned integer that scales the contribution of the partition factor.

<DT> PriorityWeightQOS

<DD> An unsigned integer that scales the contribution of the quality of service factor.

</DL>

 

<P> Note:  As stated above, the five priority factors range from 0.0 to 1.0.  As such, the PriorityWeight terms may need to be set to a high enough value (say, 1000) to resolve very tiny differences in priority factors.  This is especially true with the fair-share factor, where two jobs may differ in priority by as little as .001. (or even less!)</P>

 

<!-------------------------------------------------------------------------->

<a name=configexample>

<h2>Configuration Example</h2></a>

 

<P> The following are sample slurm.conf file settings for the

  Multi-factor Job Priority Plugin.</P>

 

<P> The first example is for running the plugin applying decay over

  time to reduce usage.  Hard limits can be used in this

  configuration, but will have less effect since usage will decay

  over time instead of having no decay over time.</P> 

<PRE>

# Activate the Multi-factor Job Priority Plugin with decay

PriorityType=priority/multifactor

 

# 2 week half-life

PriorityDecayHalfLife=14-0

 

# The larger the job, the greater its job size priority.

PriorityFavorSmall=NO

 

# The job's age factor reaches 1.0 after waiting in the

# queue for 2 weeks.

PriorityMaxAge=14-0

 

# This next group determines the weighting of each of the

# components of the Multi-factor Job Priority Plugin.

# The default value for each of the following is 1.

PriorityWeightAge=1000

PriorityWeightFairshare=10000

PriorityWeightJobSize=1000

PriorityWeightPartition=1000

PriorityWeightQOS=0 # don't use the qos factor

</PRE>

 

<P> This example is for running the plugin with no decay on usage,

  thus making a reset of usage necessary.</P>

<PRE>

# Activate the Multi-factor Job Priority Plugin with decay

PriorityType=priority/multifactor

 

# apply no decay

PriorityDecayHalfLife=0

 

# reset usage after 28 days

PriorityUsageResetPeriod=28-0

 

# The larger the job, the greater its job size priority.

PriorityFavorSmall=NO

 

# The job's age factor reaches 1.0 after waiting in the

# queue for 2 weeks.

PriorityMaxAge=14-0

 

# This next group determines the weighting of each of the

# components of the Multi-factor Job Priority Plugin.

# The default value for each of the following is 1.

PriorityWeightAge=1000

PriorityWeightFairshare=10000

PriorityWeightJobSize=1000

PriorityWeightPartition=1000

PriorityWeightQOS=0 # don't use the qos factor

</PRE>

 

<!-------------------------------------------------------------------------->

<p style="text-align:center;">Last modified 12 June 2009</p>

 

<!--#include virtual="footer.txt"-->