It is the scheduler’s objective to deliver the behavior expected by the user in a manner that maximizes the overall value of the system to its users. We have reduced this objective to the following six principles of operations:
—Priority.
The system should not degrade the performance of a high priority application in the presence of a low priority application.
—Proportional sharing among real-time and conventional applications in the same priority class.
Proportional sharing applies only if the scheduler cannot satisfy all the requests in the system. The system will fully satisfy the requests of all applications requesting less than their proportional share. The resources left over after satisfying these requests are distributed proportionally among tasks that can use the excess. While it is relatively easy to control the execution rate of conventional applications, the execution rate of a real-time application is controlled by selectively shedding computations in as even a rate as possible.
—Graceful transitions between fluctuations in load.
The system load varies dynamically, new applications come and go, and the resource demand of each application may also fluctuate. The system must be able to adapt to the changes gracefully, particularly by being able to effectively utilize available resources when the system is heavily loaded.
—Satisfying real-time constraints and fast interactive response time in underload.
If real-time and interactive tasks request less than their proportional share, their time constraints should be honored when possible, and the interactive response time should be short.
—Trading off instantaneous fairness for better real-time and interactive response time.
While it is necessary that the allocation is fair on average, insisting on being fair instantaneously at all times can cause many more deadlines to be missed and deliver poor response time to short running tasks. We will tolerate some instantaneous unfairness so long as the extent of the
unfairness is bounded. For example, a long-running batch application can tolerate some extra short-term delay without any noticeable loss in overall performance to allow a real-time application to meet its immediate deadline. This is the same motivation behind the design of multi-level feedback schedulers to improve the response time of interactive tasks.
—Notification of resource availability.
SMART allows applications to specify if and when they wish to be notified if it is unlikely that their computations will be able to complete before their given deadlines.
