A Nemesis scheduler has several goals: to reduce the QoS crosstalk between applications; to enable application-specific degradation under load; to support applications which need some baseline resource by providing some real guarantees on CPU allocation.
A key concept is that applications should be allocated a share of the processor. These shares are allocated by the QoS Manager, based on an understanding of the available resources and input from the QoS Controller (and hence from both applications and the user). A key decision was made in order to simplify the computation required by the scheduler on context switches -- the QoS Manager will ensure that the scheduler can always meet its short term demands by ensuring that less than 100% of the processor is ``contracted out'' to domains requiring QoS.
The QoS Manager takes a long term view of the availability of resources and uses algorithms with significant hysteresis to provide a consistent guaranteed resource to the application. However, this does not imply that the system is not work-conserving - any ``slack'' time in the system is supplied to those applications that request it with the information that this is ``optimistic'' processor capacity and they should not adapt their behaviour to rely upon it.
A mechanism for specifying CPU time QoS must serve three purposes: it must allow applications, users, or user agents to specify an application's desired CPU time, enable the QoS Manager to ensure the processor resource is not over allocated and enable the scheduler to allocate processor time efficiently.
As decribed in section ii, Nemesis adopts an approach in which users or user agents are expected to provide overall control (by observation) of resouce allocation. This leads to a simple QoS specification. In the case of CPU time, there is further advantage in a simple QoS specification: it reduces the overhead for the scheduler in recalculating a schedule during a context switch.