The system administrator can allocate CPU resources according to predefined shares as opposed to fixed percentages, which allows the system to dynamically apportion all available resources according to the relative proportion f shares f any current user. The SRM pro rates resource shares to users and groups and then adjusts CPU usage to meet the shares.
Dr. Gunther presents two significant differences between the TS and SRM schedulers. The first is that the SRM guarantees a minimum percentage f CPU, rather than a fixed percentage. The other difference is that when the allocations are changed dynamically, the SRM changes are not always immediately reflected the in percentages f CPU time the users receive. Dr. Gunther's first example explains that if a user is awarded 10 f 100 shares, that user receives a minimum f 10% f the CPU resources when the machine is busy. If the machine is only 50% active, the same user will receive double or 20% f the CPU resources. This CPU usage is determined by an instantaneous and periodic sampling f the usage to adjust the resource usage. Since the usage has to be sampled and adjusted, this causes a time lag between the allocation and the realization f resources. ...
The goal f the SRM is to dynamically adjust each user's CPU usage to reflect the ratio f shares to which the user is entitled. Dr. Gunther uses a modeling tool called PDQ to demonstrate several capacity planning scenarios. The first scenario presents two small share users in one group. The data compares TS and SRM response times as well as comparisons f SRM response times between scenarios. The user with fewer shares in the first scenario has a longer wait than with traditional TS schedulers. The wait is significantly longer for a small share user when a large share user is brought online in the second scenario. When two groups are active in the third scenario, the group with smaller shares suffers performance degradation. The fourth scenario presents results from all three groups being active. The groups with the largest number f shares have significant performance improvement while the opposite occurs for the small share groups. Gunther points out that allowing a sudden swing in response times by an order f magnitude or more is highly undesirable when allocating SRM shares and this has to be considered when a particular group is given too many resource shares. In addition, a single user from a different group can have a large impact on a separate group.
Dr. Gunther recommends a method to use when setting the SRM tuning parameters. If on a particular system, the service demands and workload intensity are less relative to the case studies presented, Gunther predicts the SRM will performance will be better than predicted. If each user has more than one process executing at a time or if there is a great disparity in the work performed by