Here, the quantitative restriction is to ensure that the application receives a stable, predictable processor share. From the application's perspective, it should appear as if it were executing on a virtual processor of the equivalent speed.
Constraining CPU usage of an application utilizes the general strategy
described earlier. The application is sandboxed using a monitor process
that either starts the application or attaches to it at run time.
The monitor process periodically samples the
underlying performance monitoring infrastructure to estimate a
progress metric. In this case, progress can be defined as the portion
of its CPU requirement that has been satisfied over a period of time.
This metric can be calculated as the ratio of the allocated CPU time
to the total time this application has been ready for execution in
this period. However, although most OSes provide the former
information, they do not yield much information on the latter. This is
because few OS monitoring infrastructures distinguish (in what gets
recorded) between time periods where the process is waiting for a
system event and where it is ready waiting for another process to
yield the CPU. To model the virtual processor behavior of an
application with wait times (see Figure 1 for a
depiction of the desired behavior), we use a heuristic to estimate the
total time the application is in a wait state. The heuristic
periodically checks the process state, and assumes that the process
has been in the same state for the entire time since the previous check.
The actual CPU share allocated to the application is controlled by periodically determining whether the granted CPU share exceeds or falls behind the desired threshold. The guiding principle is that if other applications take up excessive CPU at the expense of the sandboxed application, the monitor compensates by giving the application a higher share of the CPU than what has been requested. However, if the application's CPU usage exceeds the prescribed processor share, the monitor would reduce its CPU quantum for a while, until the average utilization drops down to the requested level. While the application is waiting for a system event (e.g., arrival of a network message), it is waiting for resources other than the CPU. Consequently, the time in a waiting state is not included in estimating the CPU share and the application would not get compensated for being in a wait state. For this scheme to be effective, the lifetime of the application needs to be larger than the period between sampling points where the progress metric is recomputed.
Next: Memory Resources Up: Enforcing Quantitative Restrictions Previous: Enforcing Quantitative Restrictions