LSF Version 7.3 - Administering Platform LSF

Administering Platform LSF 309
Fairshare Scheduling
The Development group gets the largest share (50%) of the resources in the event
of contention. Shares assigned to the Development group can be further divided
among the Systems, Application, and Test groups, which receive 15%, 35%, and
50%, respectively. At the lowest level, individual users compete for these shares as
usual.
One way to measure a user’s importance is to multiply their percentage of the
resources at every level of the share tree. For example,
User1 is entitled to 10% of
the available resources (.50 x .80 x .25 = .10) and
User3 is entitled to 4% (.80 x .20 x
.25 = .04). However, if Research has the highest dynamic share priority among the
3 groups at the top level, and ChipY has a higher dynamic priority than ChipX, the
next comparison is between
User3 and User4, so the importance of User1 is not
relevant. The dynamic priority of
User1 is not even calculated at this point.
Queue-based Fairshare
When a priority is set in a queue configuration, a high priority queue tries to
dispatch as many jobs as it can before allowing lower priority queues to dispatch any
job. Lower priority queues are blocked until the higher priority queue cannot
dispatch any more jobs. However, it may be desirable to give some preference to
lower priority queues and regulate the flow of jobs from the queue.
Queue-based fairshare allows flexible slot allocation per queue as an alternative to
absolute queue priorities by enforcing a soft job slot limit on a queue. This allows
you to organize the priorities of your work and tune the number of jobs dispatched
from a queue so that no single queue monopolizes cluster resources, leaving other
queues waiting to dispatch jobs.
You can balance the distribution of job slots among queues by configuring a ratio
of jobs waiting to be dispatched from each queue. LSF then attempts to dispatch a
certain percentage of jobs from each queue, and does not attempt to drain the
highest priority queue entirely first.
When queues compete, the allocated slots per queue are kept within the limits of
the configured share. If only one queue in the pool has jobs, that queue can use all
the available resources and can span its usage across all hosts it could potentially
run jobs on.