Configure a share tree


Group membership is already defined in the UserGroup section of lsb.users. To configure a share tree, use the USER_SHARES column to describe how the shares are distributed in a hierarchical manner. Use the following format.
Begin UserGroup 
GroupB       (User1 User2)          () 
GroupC       (User3 User4)          ([User3, 3] [User4, 4]) 
GroupA       (GroupB GroupC User5)  ([User5, 1] [default, 10]) 
End UserGroup
  • User groups must be defined before they can be used (in the GROUP_MEMBER column) to define other groups.

  • Shares (in the USER_SHARES column) can only be assigned to user groups in the GROUP_MEMBER column.

  • The keyword all refers to all users, not all user groups.

  • Enclose the share assignment list in parentheses, as shown, even if you do not specify any user share assignments.


An Engineering queue or host partition organizes users hierarchically, and divides the shares as shown. It does not matter what the actual number of shares assigned at each level is.

The Development group gets the largest share (50%) of the resources in the event of contention. Shares that are 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.