D ec 2 01 5 Mixed-Criticality Scheduling with I / O

This paper addresses the problem of scheduling tasks with different criticality levels in the presence of I/O requests. In mixed-criticality scheduling, higher criticality tasks are given precedence over those of lower criticality when itis impossible to guarantee the schedulability of all tasks. Wh ile mixed-criticality scheduling has gained attention in recent years, most approaches typically assume a periodic task model. Thi s assumption does not always hold in practice, especially for realtime and embedded systems that perform I/O. For example, many tasks block on I/O requests until devices signal their completion via interrupts; both the arrival of interrupts a nd the waking of blocked tasks can be aperiodic. In our prior work, we developed a scheduling technique in the Quest realtime operating system, which integrates the time-budgetedmanagement of I/O operations with Sporadic Server scheduling o f tasks. This paper extends our previous scheduling approach with support for mixed-criticality tasks and I/O requests on the same processing core. Results show the effective schedulab ility of different task sets in the presence of I/O requests is supe rior in our approach compared to traditional methods that manage I/O using techniques such as Sporadic Servers. I. I NTRODUCTION Mixed-criticality scheduling orders the execution of task s of different criticality levels. Criticality levels are ba sed on the consequences of a task violating its timing requirement s, or failing to function as specified. For example, DO-178B is a software certification used in avionics, which specifies several assurance levels in the face of software failures. T hese assurance levels range from catastrophic (e.g., could caus e a plane crash) to non-critical when they have little or no impact on aircraft safety or overall operation. Mixed-crit i ality scheduling was first introduced by Vestal (2007) [1]. Later, Baruah, Burns and Davis (2011) [2] introduced Adaptive Mixed-Criticality (AMC) scheduling. The work presented in this paper builds upon AMC to extend it for use in systems where tasks make I/O requests. Our approach to AMC with I/O is based on experience with our in-house real-time operatin g system, called Quest [3]. Quest can be configured to have two privilege levels, with the more privileged kernel being separated from a less privileged userspace. This is similar to traditional opera ting systems such as Linux. In contrast, an alternative system configuration, called Quest-V, supports three privilege le vels. The third privilege level in Quest-V is more trusted than the kernel, and operates as a lightweight virtual machine monit or, or hypervisor. Unlike with traditional virtual machine sys tems, Quest-V uses its most trusted privilege level to partition resources amongst (guest) sandbox domains. Each sandbox domain then manages its own resources independently and in isolation of other sandbox domains, without recourse to a hypervisor. This leads to a far more efficient design, where virtualization overheads are almost entirely eliminated. As has been shown in prior work, it is possible to dedicate separate tasks of different criticality levels to different sandbox es in Quest-V [4]. This is demonstrated in Figure 1. Note that each sandbox has a different criticality level with level 0 being the least critical. However, Quest-V has thus far not considere tasks of different criticality levelswithin the same sandbox and, hence, for scheduling on the same (shared) processor cores. In this paper, we show how to integrate the processing of I/O events and tasks in an Adaptive Mixed-Criticality [2] scheduling framework built within the Quest kernel. We exte nd Quest with support formode changesbetween different criticality levels. This enables components of different criti ally levels to coexist in a single Quest-V sandbox or in a traditio nal Quest system, as depicted in Figure 2. Fig. 1: Mixed-Criticality Levels Across Separate Quest-V S andboxes Previous mixed-criticality analysis assumes that all jobs in the system are scheduled under the same policy, typically as periodic tasks. However, as previously shown by Danish, Li and West [5], using the same scheduling policy for both task threads and bottom half interrupt handlers 1 esults in lower 1Bottom half interrupt handlers perform deferrable functio nality necessary when an interrupt from a device occurs.