arxiv: v3 [cs.os] 12 Mar 2016

Transcription

1 Mxed-Crtcalty Schedulng wth I/O Erc Mssmer, Katherne Zhao and Rchard West Computer Scence Department Boston Unversty Boston, MA Emal: arxv: v3 [cs.os] 12 Mar 2016 Abstract Ths paper addresses the problem of schedulng tasks wth dfferent crtcalty levels n the presence of I/O requests. In mxed-crtcalty schedulng, hgher crtcalty tasks are gven precedence over those of lower crtcalty when t s mpossble to guarantee the schedulablty of all tasks. Whle mxed-crtcalty schedulng has ganed attenton n recent years, most approaches typcally assume a perodc task model. Ths assumpton does not always hold n practce, especally for realtme and embedded systems that perform I/O. In pror work, we developed a schedulng technque n the Quest real-tme operatng system, whch ntegrates the tme-budgeted management of I/O operatons wth Sporadc Server schedulng of tasks. Ths paper extends our prevous schedulng approach wth support for mxed-crtcalty tasks and I/O requests on the same processng core. Results show that n a real mplementaton the mxedcrtcalty schedulng method ntroduced n ths paper outperforms a schedulng approach consstng of only Sporadc Servers. I. INTRODUCTION Mxed-crtcalty schedulng orders the executon of tasks of dfferent crtcalty levels. Crtcalty levels are based on the consequences of a task volatng ts tmng requrements, or falng to functon as specfed. For example, DO-178B s a software certfcaton used n avoncs, whch specfes several assurance levels n the face of software falures. These assurance levels range from catastrophc e.g., could cause a plane crash) to non-crtcal when they have lttle or no mpact on arcraft safety or overall operaton. Mxed-crtcalty schedulng was frst ntroduced by Vestal 2007) [1]. Later, Baruah, Burns and Davs 2011) [2] ntroduced Adaptve Mxed-Crtcalty AMC) schedulng. The work presented n ths paper bulds upon AMC to extend t for use n systems where tasks make I/O requests. Ths s the frst paper to address the ssue of I/O schedulng n an Adaptve Mxed- Crtcalty scenaro. Our approach to AMC wth I/O s based on experence wth our n-house real-tme operatng system, called Quest [3]. Quest can be confgured to have two prvlege levels, wth the more prvleged kernel beng separated from a less prvleged user-space. Ths s smlar to tradtonal operatng systems such as Lnux. In contrast, an alternatve system confguraton, called Quest-V, supports three prvlege levels. The thrd prvlege level n Quest-V s more trusted than the kernel, and operates as a lghtweght vrtual machne montor, or hypervsor. Unlke wth tradtonal vrtual machne systems, Quest-V uses ts most trusted prvlege level to partton resources amongst guest) sandbox domans. Each sandbox doman then manages ts own resources ndependently and n solaton of other sandbox domans, wthout recourse to a hypervsor. Ths leads to a far more effcent desgn, where vrtualzaton overheads are almost entrely elmnated. It has been shown n pror work that t s possble to dedcate separate tasks of dfferent crtcalty levels to dfferent sandboxes n Quest-V [4]. Ths s demonstrated n Fgure 1. Note that each sandbox has a dfferent crtcalty level wth level 0 beng the least crtcal. However, Quest-V has thus far not consdered tasks of dfferent crtcalty levels wthn the same sandbox and, hence, for schedulng on the same shared) processor cores. In ths paper, we show how to ntegrate the processng of I/O events and tasks n an Adaptve Mxed-Crtcalty [2] schedulng framework bult wthn the Quest kernel. We extend Quest wth support for mode changes between dfferent crtcalty levels. Ths enables components of dfferent crtcally levels to coexst n a sngle Quest-V sandbox or n a tradtonal Quest system, as depcted n Fgure 2. Fg. 1: Mxed-Crtcalty Levels Across Separate Quest-V Sandboxes Prevous mxed-crtcalty analyss assumes that all jobs n the system are scheduled under the same polcy, typcally as perodc tasks. However, as prevously shown by Dansh, L and West [5], usng the same schedulng polcy for both task threads and bottom half nterrupt handlers 1 results n lower I/O performance and larger overheads. Specfcally, the authors 1 We use the Lnux termnology, where the top half s the non-deferrable work that runs n nterrupt context, and the bottom half s the deferrable work executed n a thread context after the top half. 1

2 Fg. 2: Quest Support for Mxed-Crtcalty Schedulng compared the Sporadc Server SS) [6] model for both man threads and bottom half nterrupt handlers to usng Sporadc Servers for man threads and Prorty Inhertance Bandwdthpreservng Servers PIBS) for bottom half threads. The results showed that by usng PIBS for nterrupt bottom half threads, the schedulng overheads are reduced and I/O performance s ncreased. The detals of PIBS wll be dscussed n Secton II. The contrbutons of ths paper nclude a mxed-crtcalty analyss assumng threads are scheduled usng ether the Sporadc Server or PIBS schedulng model. It s shown that whle a system of Sporadc Servers and PIBS has a slghtly lower schedulablty than a system of only Sporadc Servers from a theoretcal pont of vew, n practce a real mplementaton of both schedulng polces results n Sporadc Server and PIBS outperformng a system of only Sporadc Servers. The rest of the paper s organzed as follows. Secton II provdes the necessary background nformaton on Sporadc Servers and PIBS and ntroduces a response tme analyss for them. Next, Secton III brefly dscusses the Adaptve Mxed-Crtcalty AMC) model. Secton IV contans the AMC schedulng analyss for a system of Sporadc and Prorty Inhertance Bandwdth Preservng Servers. Secton V dscusses the mplementaton detals of our AMC approach n the Quest operatng system. Secton VI dscusses expermental results, whle related work s descrbed n Secton VII. Fnally, conclusons are dscussed n Secton VIII. II. SPORADIC SERVER AND PIBS Sporadc Servers SS) [6] and Prorty Inhertance Bandwdth-preservng Servers PIBS) [5] are the two schedulng models used n the Quest real-tme operatng system [3]. Sporadc Servers are specfed usng a budget capacty, C, and perod T. By default, the Sporadc Server wth the smallest perod s gven hghest prorty, whch follows the rate-monotonc polcy [7]. The man tasks n Quest run on Sporadc Servers, thereby guaranteeng them a mnmum share of CPU tme every real-tme perod. Replenshment lsts are used to track the consumpton of CPU tme and when t s elgble to be re-appled to the correspondng server. PIBS uses a much smpler schedulng method whch s more approprate for the short executon tmes assocated wth nterrupt bottom half threads. A PIBS s specfed by a utlzaton, U. A PIBS always runs on behalf of a Sporadc Server and nherts both the prorty and perod of the Sporadc Server. For example, the PIBS runnng n response to a devce nterrupt would run on behalf of the Sporadc Server that requested the I/O acton to be performed. The capacty of a PIBS s calculated as C=U T, where T s the perod of the Sporadc Server. As wth Sporadc Servers, PIBS uses replenshments but nstead of a lst there s only a sngle replenshment. When a PIBS has executed C actual, ts next replenshment s set to t+c actual /U, where t s the tme the PIBS started ts most recent executon. A PIBS cannot execute agan untl the next replenshment tme regardless of whether t has utlzed ts entre budget or not. Snce a PIBS uses only one replenshment value rather than a lst, t s benefcal for schedulng shortlved nterrupt servce routnes that would otherwse fragment a Sporadc Server s budget nto many small replenshments. The replenshment method of a PIBS lmts ts mum utlzaton wthn any sldng wndow of sze T to 2 U)U. Ths occurs when the PIBS frst runs for C 1 =UT UT) and then agan for C 2 =UT. Ths s demonstrated n Fgure 3: C 1 +C 2 T = T U)+C 2 T = T C 2)U +C 2 T = C 2/U C 2 )U +C 2 C 2 /U = 2 U)U Fg. 3: PIBS Server Utlzaton The nteracton between Sporadc Servers and PIBS s depcted n Fgure 4. Frst, the Sporadc Server ntates an I/O related system call Step 1). The system call nvokes the assocated devce drver, whch programs the devce Step 2). The devce wll eventually ntate an nterrupt whch s handled by the top half nterrupt handler Step 3). The top half nterrupt handler wll acknowledge the nterrupt and wake up one of the PIBS to handle the majorty of the work assocated wth the nterrupt Step 4). Note that although the fgure shows PIBS run at kernel-level, they could just as well be assocated wth user-space threads f the system granted such prvleges. Fnally, after a PIBS fnshes executng t wll wake up the correspondng Sporadc Server, assumng the Sporadc Server was blocked on an I/O request Step 5). A more detaled descrpton of the schedulng of PIBS and Sporadc Servers can be found n pror work 2011) [5]. 2

3 Fg. 4: Sporadc Server and PIBS Interacton The advantages of usng PIBS for bottom half nterrupt handlng nclude lower schedulng overhead and no delayed executon due to replenshment lst fragmentaton. The short executon tme of bottom half nterrupt handlers can cause a Sporadc Server to complete executon before exhaustng ts avalable capacty. Ths leads to a fragmented replenshment lst. In practce, the lsts are fnte n length because of memory constrants and to lmt schedulng overhead. When a replenshment lst s full, tems are merged to make space for new replenshments. Ths causes the avalable budget to be deferred [8], and the effectve utlzaton of the Sporadc Server can drop below ts specfed value. Ths n turn results n deadlnes beng mssed. In contrast, PIBS have only a sngle replenshment lst tem and a dfferent polcy for how the replenshment s posted, whch prevents a drop n ther effectve utlzaton and lower schedulng overhead. Fgure 5 shows an example of replenshment lst fragmentaton. The frst task, τ 1, begns executon at tme t=0 and contnues executon for eght tme unts. τ 1 utlzed ts entre capacty at t=8 so a sngle sngle replenshment tem s posted for 8 tme unts of capacty at tme t=16. The replenshment s posted at t=16 because τ 1 started executon at tme t=0 and has a perod of 16. Rght at the completon of ts executon τ 1 ntates an I/O related event, e.g. a read. Suppose ths I/O event causes four nterrupts to occur. Each nterrupt ntates a bottom half thread that takes one tme unt of computaton to complete.τ 1 wll requre all four bottom half nterrupt handlers to complete executon before t can contnue executon, e.g. t s blockng on the read. τ 2 s the task responsble for handlng these bottom half nterrupt handlers. The frst nterrupt occurs at tme t=9 and s mmedately handled by τ 2. Note that at tme t=9 the tme of the head replenshment lst tem s updated from zero to nne. Ths s to ensure that when a replenshment tem s posted after the task blocks or depletes ts budget the replenshment tem s posted at the correct tme. Once τ 2 completes executon of the bottom half nterrupt handler t blocks as t wats for another I/O nterrupt to occur. When τ 2 blocks t posts a replenshment tem for the capacty that t used. Snce t used 1 tme unt of capacty and started executng at tme t=9 a replenshment tem of 1 tme unt s posted at tme t=25. At tme t = 11 another nterrupt occurs, wakng up τ 2 for another tme unt. The tme of the frst replenshment lst tem s updated to 11 to reflect that the Sporadc Server started executon at tme t=11. After handlng the bottom half nterrupt handler, another replenshment tem for one tme unt s posted, ths tme at tme t=27. When the thrd nterrupt occurs τ 2 agan executes for 1 tme unt. However, when τ 2 attempts to post a replenshment tem for the one unt of capacty used t cannot snce ts replenshment lst s full. 2 In order to ensure that τ 2 does not adversely affect other runnng tasks, ts remanng capacty of one tme unt s merged wth the next replenshment lst tem, whch n ths example s at t=25. Ths results n the avalable capacty for τ 2 beng zero, leavng t unable to mmedately handle the nterrupt that occurs at tme t=15. Instead, the executon of the nterrupt s delayed and completes only at tme t=26. Meanwhle, τ 1, whch had the capacty to execute at tme t=16, s blockng watng for completon of the fourth nterrupt handler. τ 1 begns executon at tme t=26 but that leaves only sx tme unts untl the deadlne at tme t=32, nstead of the eght requred to complete executon. Fg. 5: Example Task and I/O Schedulng usng Sporadc Servers Fgure 6 shows a smlar schedulng scenaro. However, ths tme the nterrupt bottom halves are handled by a PIBS. As wth the prevous scenaro, τ 1 ntates an I/O related event at tme t=8 and blocks untl the completon of the event. The frst nterrupt occurs at tme t=9 and s mmedately handled by PIBS. As wth the Sporadc Server, the tme n the replenshment lst tem s updated to reflect when the PIBS started executon. Once the event s handled, the PIBS posts a sngle replenshment tem at tme t=13. Ths s because τ 2 s runnng on behalf of τ 1 so t nherts both the prorty and perod of τ 1. Snce τ 2 executed for only 25% of ts avalable four tme unts of capacty the replenshment s posted 25% of ts perod from when t started executon. The second nterrupt 2 For the sake of ths example the replenshment lst sze s three. In practce, a larger replenshment lst sze would be chosen but, regardless, fragmentaton and capacty postponement can occur [5]. 3

4 occurs at tme t=11 but ts executon s deferred untl τ 2 has avalable capacty. At tme t=13 the thrd nterrupt arrves and τ 2 has the capacty to handle both t and the prevous nterrupt. Fnally, the fourth nterrupt arrves at tme t=15, whch can also be handled by τ 2. Snce τ 2 has executed for 75% of ts avalable capacty a replenshment s posted twelve tme unts after t started executon, at t=25. Ths permts τ 1 to contnue executon at tme t=16. The pattern then repeats tself. Ths smple example demonstrates the advantages of PIBS for bottom half threads compared to Sporadc Servers. Fnally, note that even f the replenshment lst n the frst example had been long enough to avod the delayed budget, the Sporadc Server would have experenced twce as much context swtchng overhead compared to the equvalent PIBS. Fg. 6: Example Task and I/O Schedulng usng Sporadc Servers & PIBS Note that n the frst example, f a dfferent polcy for handlng a full Sporadc Server replenshment lst had been chosen,τ 2 mght have completed n tme forτ 1 to fnsh before ts deadlne. For example, f the later replenshment tems were merged nstead of the head replenshment tem, τ 2 would have had one remanng tme unt of capacty to handle the last bottom half nterrupt handler. However, as more nterrupts occur, ths temporary fx wll no longer work as more capacty s delayed further n tme. A. Response Tme Analyss for SS and PIBS In order to perform an Adaptve Mxed-Crtcalty analyss for a combned Sporadc Server and PIBS system, the response tme analyss equaton of the system must be derved. Frst, under the assumpton that a Sporadc Server can be treated as an equvalent perodc task [6], the response tme equaton for task τ n a system of only Sporadc Servers s the followng: R = C R C j τ j hp) where hp) s the set of tasks of equal or hgher prorty than task τ. Second, due to the worst-case phasng of a combned system of PIBS and Sporadc Servers, a PIBS utlzaton bound of 2 U)U cannot repeatedly occur. The worst case phasng can result n at most an addtonal capacty.e., executon tme) of T q T q U k )U k for PIBS τ k assgned to the Sporadc Server τ q. Ths s only possble f PIBS blocks watng on I/O before consumng ts full budget capacty. Therefore, a tghter upper-bound on the nterference a PIBS can cause s: I q t k t) = T q T q U k )U k + T q U k T q t = 1 U k )T q U k + T q U k = 1+ t T q T q U k ) T q U k Ths can be ncorporated nto the response tme analyss of Sporadc Server τ, n a system consstng of both Sporadc Servers and PIBS, n the followng way: R = C } R C j τ j hp) τ k ps τ Iq k R )} 1) q hp) Where ps s the set of all PIBS and hp)=hp) τ },.e. the set contanng τ and all tasks wth equal or hgher prorty than task τ. Ths s necessary as the PIBS can be runnng on behalf of task τ. In general, there s no a- pror knowledge about whch PIBS runs for whch Sporadc Server. Therefore, the Sporadc Server, τ q that mzes the nterference caused by the PIBS must be consdered. If such a-pror knowledge exsted, t could be used to reduce the possble set of Sporadc Servers on behalf of whch a PIBS could be executng. However, wthout such knowledge all possble Sporadc Server tasks of equal or hgher prorty must be consdered. The response tme analyss for a PIBS s therefore dependent on the assocated Sporadc Server. The response tme analyss for PIBS τ p when assgned to Sporadc Server τ s s: sr p =2 U p )U p T s + τ k ps\τ p} τ j hps) sr p C j } τ Iq k sr p )} 2) q hps) Note that 2 U p )U p T s s the mum executon tme of the PIBS over a tme wndow of T s,.e. I s p T s)=2 U p )U p T s. Besdes the frst terms dfferng, Equaton 2 dffers from Equaton 1 n that hps) s used nstead of hps) for the set of Sporadc Servers. Ths s because Sporadc Server τ s must be ncluded as t has an equal prorty to PIBS τ p when τ p s runnng on behalf of τ s. Also, the summaton over all PIBS does not nclude PIBS τ p when determnng ts response tme. If s R p T s, for each and every Sporadc Server τ s that τ p can be assgned to, then τ p wll never mss a deadlne. III. BACKGROUND: AMC SCHEDULING Ths secton wll provde the necessary background nformaton on Adaptve Mxed-Crtcalty AMC) schedulng [2] to 4

5 understand the analyss n Secton IV. A more detaled analyss can be found n Baruah 2011) [2]. In AMC, a task τ s defned by ts perod, deadlne, a vector of computaton tmes and a crtcalty level, T,D, C ),L. In the smplest case, L LO,HI},.e. there are two crtcalty levels LO and HI where HI>LO. For tasks for whch L=LO, CHI) s not defned as there are no HI-crtcalty versons of these tasks to execute. For HI-crtcalty tasks CHI) CLO). The system also has a crtcalty level and t ntally starts n the LO-crtcalty mode. Whle runnng n the LO-crtcalty mode, both LO- and HI-crtcalty tasks execute, and whle runnng n HI-crtcalty mode, only HI-crtcalty tasks execute. If a hgh crtcalty task exhausts ts CLO) before fnshng ts current job, the system swtches nto the HI-crtcalty mode and suspends all LO-crtcalty tasks. Ths requres a sgnalng mechansm avalable to tasks to sgnal that they have completed executon of a specfc job nstance. The schedulablty test for AMC conssts of three parts: 1) the schedulablty of the tasks when the system s n the LOcrtcalty state, 2) the schedulablty of the tasks when the system s n the HI-crtcalty state and 3) the schedulablty of the tasks durng the mode change from LO-crtcalty to HI-crtcalty. The frst two are smple and can be handled wth the tradtonal response tme analyss, takng nto account the approprate set of tasks and worst case executon tmes. Specfcally, the response tme analyss for each task τ when the system s n the LO-crtcalty state s: R LO = C LO) LO τ j hp) τ j hph) and the response tme analyss for the HI-crtcalty state s: R HI = C HI) R HI where hph) s the set of all hgh-crtcalty tasks wth a prorty hgher than or equal to that of task τ. What remans s whether all HI-crtcalty tasks wll meet ther deadlnes durng the mode change from LO-crtcalty to HI-crtcalty. Baruah, Burns and Davs provded two suffcent but not complete schedulng tests for the crtcalty mode,.e. the tests wll not admt task sets that are not schedulable but may reject task sets that are schedulable. The frst s AMCrtb response tme bound) whch derves a new response tme analyss equaton for the mode change. The second s AMC whch derves an expresson for the mum nterference a HI-crtcalty task can experence durng the mode change. AMC- terates over all possble ponts n tme where the nterference could ncrease, takng the mum of these ponts. AMC- s more computatonally expensve than AMC-rtb but domnates AMC-rtb by permttng certan task sets that AMC-rtb rejects, and acceptng any task set that AMC-rtb accepts. Both tests use Audsley s prorty-assgnment algorthm [9], as prortes that are nversely related to perod are not optmal for AMC [1], [2]. In ths paper, we focus on the use of AMC-rtb for response tme analyss of a system wth Sporadc Servers and PIBS. Ths s because of the added expense ncurred by AMC-, whch must terate over all tme ponts when LO-crtcalty tasks are released. The AMC-rtb analyss starts wth a modfed form of the tradtonal perodc response tme analyss: R = C τ j hp) C j mnl,l j )) 3) Where mnl,l j ) returns the lowest crtcalty level passed to t, e.g. n the case of a dual-crtcalty level system, HI s only returned f both arguments are HI. The use of mn mples that we only consder crtcalty levels equal to or less than the crtcalty level of τ. If we dvde the hgher prorty tasks by crtcalty level, we obtan the followng: R = C R C j mnl,l j )) τ j hph) τ j hpl) 4) Where hpl) s the set of all LO-crtcalty tasks wth a prorty hgher than or equal to the prorty of task τ. The mn n the thrd term s replaced wth LO as we know L j =LO. Snce we are only concerned wth hgh prorty tasks after the mode change,.e. L =HI, Equaton 4 becomes: R = C HI) R τ j hph) τ j hpl) 5) Fnally, the response tme bound can be tghtened even further by recognzng that LO-crtcalty tasks can only nterfere wth HI-crtcalty tasks before the change has occurred. Wth ths observaton the fnal AMC response tme bound equaton s: R = C HI) R τ j hph) τ j hpl) LO 6) A. LO-crtcalty tasks runnng n the HI-crtcalty mode Burns and Baruah [10] provde an extenson to AMC that permts lower crtcalty tasks to contnue executon n the HIcrtcalty state. Ths extenson s used n our AMC model wth support for I/O, whch s brefly summarzed as follows: If LO-crtcalty tasks are allowed to contnue executon n the HI-crtcalty mode at a lower capacty, the followng s 5

6 the response tme for a HI-crtcalty task τ : R = C R τ j hph) τ j hpl) τ j hpl) LO ) R LO 7) The fnal term n Equaton 7 expresses the mum number of tmes the LO-crtcalty task wll be released multpled by ts smaller 3 HI-crtcalty executon tme. Whle Equaton 7 also apples to LO-crtcalty tasks that contnue runnng after the mode change, a tghter bound s possble. Specfcally, f a LO-crtcalty task has already run for CHI) before the mode change then t has met ts HI-crtcalty requrement. Therefore, R LO can be replaced wth a smaller value for LOcrtcalty tasks. To ths end R LO s defned as the followng: R LO = mnc LO),C HI))+ LO τ j hp) 8) Note that R LO =R LO f L =HI and R LO R LO f L =LO, as LO-crtcalty tasks wll have a smaller capacty n the HIcrtcalty mode. Therefore, Equaton 7 can be replaced wth the followng more general equaton that s tghter for LOcrtcalty tasks: R =C R τ j hph) τ j hpl) τ j hpl) LO ) R LO 9) In Secton IV we wll use both AMC models descrbed n ths secton to derve an AMC model for a system that ncludes Prorty Inhertance Bandwdth-Preservng Servers. IV. AMC SPORADIC SERVER AND PIBS SCHEDULING Ths secton descrbes the system model for I/O Adaptve Mxed-Crtcalty IO-AMC), comprsng both Sporadc Servers and Prorty Inhertance Bandwdth-Preservng Servers PIBS). IO-AMC focuses on the schedulng of I/O events and applcaton threads n a mxed-crtcalty settng. Based on the IO-AMC model, we wll derve a response tme bound, IO- AMC-rtb, for Sporadc Servers and PIBS. 3 For LO-crtcalty tasks that can execute n HI-crtcalty mode, C LO)>C HI), whereas for HI-crtcalty tasks C HI) C LO). A. I/O Adaptve Mxed-Crtcalty Model Sporadc Servers follow a smlar model to the orgnal AMC model. A Sporadc Server task τ s assgned a crtcalty level L LO,HI}, a perod T and a vector of capactes C. The deadlne s assumed to be equal to the perod. If L =LO, τ only runs whle the system s n the LO-crtcalty mode and therefore only CLO) s defned. For HI-crtcalty tasks both CLO) and CHI) are defned and CHI) CLO). For PIBS, an I/O task τ k s agan assgned to ether the LO or HI crtcalty level; L k LO,HI}. As prevously dscussed, PIBS are only defned by a utlzaton U k. The perod, deadlne and prorty for a PIBS s nherted from the Sporadc Server for whch t s performng a task. For IO-AMC, ths defnton s extended and each PIBS s defned by a vector of utlzatons U k. If τ k s a LO-crtcalty PIBS,.e. L k =LO, then U k LO)>U k HI) and f L k =HI then U k LO) U k HI). Ths defnton allows LO-crtcalty PIBS to contnue executon after the swtch to HI-crtcalty. Ths model allows users to assgn crtcalty levels to I/O devces ndrectly by assgnng crtcalty levels to the PIBS that execute n response to the I/O devce. Wth the typcal AMC model now augmented to consder PIBS we can now derve a new admssons test for IO-AMC. Frst, the PIBS nterference equaton ntroduced n Secton II s modfed to ncorporate crtcalty levels: ) t I q k 1+ t,l) = U k L) T q U k L) T q As before, there are three condtons that must be consdered: 1) the LO-crtcalty steady state, 2) the HI-crtcalty steady state, and 3) the change from LO-crtcalty to HIcrtcalty. The steady states are agan smple and are merely extensons of the non-mxed-crtcalty response tme bounds. For Sporadc Server tasks the steady state equatons are: R LO = C LO) τ j hp) R HI = C HI) LO τ q hp) τ k ps τ j hph) I q k HI τ q hph) τ k ps } R LO,LO)} 10) } I q k R HI,HI )} 11) where hph)=hph) τ },.e. t s the set of all HIcrtcalty tasks of hgher or equal prorty than task τ, plus task τ tself. For PIBS task τ p, runnng on behalf of Sporadc Server task τ s, the steady state equatons are: sr LO p =2 U p LO))U p LO)T s sr LO } p τ j hps) + I q k sr p LO,LO)} 12) τ q hps) τ k ps\τ p} 6

7 sr HI p =2 U p HI))U p HI)T s sr HI } p + τ j hphs) + I q k sr p HI,HI)} 13) τ q hphs) τ k ps\τ p} As wth the tradtonal response tme analyss of PIBS, ts deadlne s the same as that of ts correspondng Sporadc Server τ s. Therefore, the above analyss must be appled to all Sporadc Servers assocated wth a PIBS. B. IO-AMC-rtb The technques descrbed n Secton III are used for the IO-AMC-rtb analyss. Specfcally, LO-crtcalty PIBS are allowed to contnue executon n the HI-crtcalty mode. For a Sporadc Server task the IO-AMC-rtb equaton s: R = C R τ j hph) τ j hpl) τ k psh τ k psl τ q hph) Iq k LO τ Iq k R,HI) q hp) τ q hp) Iq k } R LO,LO ) + R R LO,HI )} 14) where psh and psl are the set of HI and LO-crtcalty PIBS respectvely. The last summaton n Equaton 14 represents the mum nterference a LO-crtcalty PIBS can cause. Specfcally, I q k RLO,LO) represents the mum nterference the PIBS can cause before the mode change and I q k R RLO,HI) represents the total nterference the PIBS can cause after the mode change. Agan, the Sporadc Server that mzes the nterference s chosen for each PIBS. The IO-AMC-rtb equaton for a PIBS τ k when assgned to Sporadc Server τ s s: srp =2 U phi))t s U p HI) srp + τ j hphs) + + τ j hpls) τ k psh\τ p}) τ k psl\τ p}) τ q hphs) Iq k sr p LO τ q hps) Iq k τ q hps) Iq k sr p,hi )} sr LO p,lo ) + sr p sr LO p,hi)} 15) Equaton 15 dffers from Equaton 14 n the frst term, and by the excluson of τ p from the set of PIBS. Smlar to Equaton 2, the response tme analyss requres teratng over all HI-crtcalty Sporadc Servers that could be assocated wth the PIBS. Ths s because only the HI-crtcalty Sporadc Servers are of nterest after the mode change. As mentoned n Secton III, recent related work by Burns and Baruah [10] has extended the orgnal AMC model to allow LO-crtcalty tasks to contnue runnng after the mode to the HI-crtcalty mode. The dervaton ths work provded was used to allowlo-crtcalty PIBS to contnue runnng after the mode change. Ths work can also be appled to allow LO-crtcalty Sporadc Servers to contnue runnng n the HIcrtcalty mode. Ths dervaton s smlar to the one provded by Burns and Baruah but there are subtle dfferences due to the ncluson of PIBS. Frst for Sporadc Servers durng the mode change the new IO-AMC-rtb equaton s: R = C τ j hph) τ j hpl) τ j hpl) τ k psh τ k psl τ q hp) Iq k LO ) R LO } τ Iq k R,HI) q hp) τ q hp) Iq k R LO,LO ) + R R LO,HI )} 16) In addton to the thrd term whch s taken from Equaton 9, Equaton 16 dffers from Equaton 14 where LO-crtcalty Sporadc Servers do not run n the HI-crtcalty mode) n that all Sporadc Servers of hgher or equal prorty must be consdered when accountng for the nterference from LOcrtcalty PIBS after the mode change. Specfcally the hph n the fnal term has changed to hp to reflect that fact that Sporadc Servers of all crtcalty levels run n the HI-crtcalty mode. Equaton 17 s the IO-AMC-rtb equaton for PIBS when LO-crtcalty Sporadc Servers are allowed to run n the HIcrtcalty mode. Agan the only dfferences are the ncluson of the nterference caused by LO-crtcalty tasks after the mode change and changng the hph to hp n the fnal term to account for the fact that all Sporadc Servers are capable of 7

8 executng after the mode change. srp =2 U phi))t s U p HI) srp + τ j hphs) τ j hpls) + + τ j hpl) sr p LO τ k psh\τ p}) τ k psl\τ p}) τ q hps) Iq k srp sr p LO ) τ q hps) Iq k τ q hps) Iq k sr p,hi)} sr LO p,lo) + sr p sr LO p,hi)} 17) V. IMPLEMENTATION Changes to the exstng Quest scheduler to support IO-AMC schedulng nclude: Mappng Quest processes to a task and job model; Detectng when to change to HI-crtcalty mode; Adjustng Sporadc Server and PIBS replenshments. Quest tasks are assgned to Sporadc Servers, and are smlar to UNIX processes n that they run untl an _ext system call s nvoked. In comparson, real-tme tasks n the IO-AMC model release a job at a specfc rate and the job runs untl completon. To accommodate the dfferences, a new sync system call was ntroduced. The sync functon ndcates the start and end of real-tme jobs. A typcal IO-AMC task has a setup phase, followed by a loop whch repeatedly calls sync before startng the body of the next job. A typcal IO-AMC applcaton wll look smlar to the procedure outlned n Algorthm 1. Algorthm 1 IO-AMC User Space Process procedure MAIN // Setup Code whle TRUE do sync) // Job Code end whle end procedure An alternatve approach would be to have one process repeatedly fork another process, wth the newly forked process beng the job for that perod. Ths approach would not requre the applcaton developer to nvoke the sync system call as the _ext system call could be used to nform the scheduler that the job s completed. Ths approach was not chosen however due to the extra overhead nvolved n the creaton of a new process. The frst tme sync s called, a mxed-crtcalty task wll sleep untl ts Sporadc Server s replenshed to full capacty. The deadlne wll be set T tme unts after the process wakes up. Subsequent calls tosync wll have the process sleep up to the deadlne, emulatng the job beng completed and watng for the next job. Quest bottom half threads are assgned to Prorty Inhertance Bandwdth Preservng Servers, and follow the real-tme task and job model. Bottom half threads are only woken up by the top halves, and at the end of ther executon they notfy the scheduler of ther completon. Therefore, no changes needed to be made to the PIBS and bottom half threads. The condtons for a mode change depend on whether a task s runnng a job or bottom half on a Sporadc Server or PIBS. AHI-crtcalty Sporadc Server ntates a mode change when t has depleted all replenshment tems that are before the deadlne. If ths happens the Sporadc Server wll not be able to run untl after the deadlne and therefore a mode change must occur. A HI-crtcalty PIBS causes a mode change when t has depleted ts budget before completng the bottom half thread. In ths case, the sngle replenshment for a PIBS wll be at the deadlne and therefore the PIBS wll not be able to run untl after ts deadlne unless a mode change occurred. Fnally, when the mode change occurs, the Sporadc Server and PIBS replenshment tems must be adjusted to take nto account the new or removed budget. For HI-crtcalty Sporadc Servers, the dfference between CHI) and CLO) s added to the begnnng of the frst replenshment lst tem, f the tem s replenshment tme s equal to or less than the current tme, or f the replenshment lst s full. Otherwse, a new replenshment lst tem s nserted at the begnnng wth a replenshment tme equal to the current tme. A replenshment tem R has two propertes, R.amt, whch s the amount of budget replenshed, and R.tme, whch s when the replenshment occurs. Ths s demonstrated n Algorthm 2. Algorthm 2 HI-Crtcalty Sporadc Server Adjustment S s the Sporadc Server beng modfed now current tme addtonal cap CHI) C LO) f S.Q.head.tme now) ORMAX LENGTH = S.Q.length) then S.Q.head.amt S.Q.head.amt + addtonal cap else R s a new replenshment tem R.tme now R.amt addtonal cap S.Q.addR) end f For LO-crtcalty Sporadc Servers, the adjustment algorthm s more complcated. If CLO) CHI) s less than or equal to the remanng budget for ths perod,.e. before the deadlne, then budget s removed from the replenshment lst by movng backwards n tme from the replenshment tem rght before the deadlne. The head replenshment tem must be treated dfferently f the Sporadc Server has used some of that budget at the tme of a mode change. S.usage tracks how much has been used from the head replenshment tem. If S.usage s greater than zero, a new replenshment tem mght be posted at the end of the queue wth an amount equal 8

9 to S.usage. If CLO) CHI) s greater than the remanng budget for ths perod then the Sporadc Server has run for more than ts CHI) for ths perod. In ths case all the avalable budget n the replenshment lst s removed for ths perod and the dfference s removed from the end of the replenshment lst. Algorthm 3 contans the pseudocode for adjustng the budget of a LO-crtcalty Sporadc Server. Algorthm 3 LO-Crtcalty Sporadc Server Adjustment S s the Sporadc Server beng modfed R d replenshment tem n S.Q rght before the deadlne of S R d s NULL f no such replenshment tem exsts now current tme reduced cap C LO) CHI) whle reduced cap > 0)ANDR d NULL) do f R d = S.Q.head)ANDS.usage > 0) then f R d.amt S.usage > reduced cap then R d.amt R d.amt reduced cap reduced cap 0 else reduced cap reduced cap R d.amt S.usage) S.Q.removeR d ) R d.amt S.usage R d.tme R d.tme+s.perod S.Q.addR d ) S.usage 0 end f R d NULL else f R d.amt reduced cap then reduced cap reduced cap R d.amt R tmp R d.prev S.Q.removeR d ) R d R tmp else R d.amt R d.amt reduced cap reduced cap 0 end f end f end whle whle reduced cap > 0 do f S.Q.end.amt reduced cap then reduced cap reduced cap S.Q.end.amt S.Q.removeS.Q.end) else S.Q.end.amt S.Q.end.amt reduced cap reduced cap 0 end f end whle PIBS have a much smpler mode change algorthm because there s only one replenshment tem to consder for each nvocaton of the server. Also, due to the aperodcty of I/O events, a deadlne for a PIBS s calculated from when an I/O event s ntated. Ths results n pessmstc analyss n Equatons 14 and 15. We have to assume that regardless of whether a PIBS s LO or HI-crtcalty, t causes the mum nterference possble n both the LO and HI modes. Therefore, both LO and HI PIBS can smply replensh ther full budget at the tme of a mode change. VI. EVALUATION The expermental evaluaton conssts of two sectons: 1) smulaton based schedulablty tests and 2) experments conducted usng the IO-AMC mplementaton n the Quest operatng system. The smulaton based schedulablty tests show that a system of Sporadc Servers and PIBS have a smlar but slghtly lower schedulablty than a system of just Sporadc Servers. Ths s due to the extra nterference that can be caused by PIBS compared to Sporadc Servers. The Quest experments show the benefts of PIBS compared to Sporadc Servers and how mxed-crtcalty can be used to control the bandwdth from I/O devces wth dfferent crtcaltes. A. Smulaton Experments In order to compare the proposed schedulng approaches, random task sets were generated wth varyng total utlzatons. 500 task sets were generated for each utlzaton value rangng from 0.20 to 0.95 wth 0.05 ncrements. Each task set was tested to see f t was schedulable under the dfferent polces. Each PIBS was randomly assgned to a sngle Sporadc Server of the same crtcalty level. For systems comprsng only Sporadc Servers, the PIBS were converted to Sporadc Servers of equvalent utlzaton and perod. 4 The parameters used to generate the task sets used are outlned n Table I. Parameter Value Number of Tasks Man, 5 I/O) Crtcalty Factor 2 Probablty L = HI 0.5 Perod Range I/O Total Utlzaton 0.05 TABLE I: Parameters Used to Generate Task Sets The UUnfast algorthm [11] was used to generate the task sets. Task perods were generated wth a log-unform dstrbuton. For the mxed-crtcalty experments, C LO)=U /T. If L =HI, C HI)=CF C LO), where CF s the crtcalty factor. For our experments, f L =LO, C HI)=0. The followng are the dfferent types of schedulablty tests that were used n the evaluaton. Ths ncludes schedulablty tests for mxed-crtcalty and tradtonal systems. leftmargn=* SS-rta Sporadc Server response tme analyss. Due to the nature of Sporadc Servers, ths s the same as a perodc response tme analyss. SS+PIBS-rta Sporadc Server and PIBS response tme analyss ntroduced n ths paper. See Secton II. AMC-rtb Adaptve Mxed-Crtcalty response tme bound developed by Baruah et al. [2]. See Secton III. IO-AMC-rtb I/O Adaptve Mxed-Crtcalty response tme bound developed n ths paper. See Secton IV. AMC UB Ths s not a schedulablty test but nstead an upper bound for AMC. It conssts of both the LO- and HI-crtcalty level steady states tests. See Secton III for detals. IO-AMC UB Ths s not a schedulablty test but nstead an upper bound for IO-AMC. It conssts of both the LO- and HI-crtcalty level steady states tests. See Secton IV for detals. 4 The PIBS perod was set equal to ts correspondng Sporadc Server. 9

10 1) SS+PIBS vs. SS-Only Smulatons: Fgure 7 contans the results of the response tme analyss and event smulator for a system of Sporadc Servers and PIBS SS+PIBS) compared to a system of only Sporadc Servers SS-Only). As expected, a hgher number of the Sporadc Server only task sets are schedulable usng the response tme analyss equatons compared to the SS+PIBS response tme analyss. Ths s due to the extra nterference a PIBS can cause compared to a Sporadc Server of equvalent utlzaton and perod. Schedulable Task Sets 100 % 80 % 60 % 40 % 20 % SS-rta SS+PIBS-rta SS+PIBS-sm SS-sm 0 % Utlzaton Fg. 7: Schedulablty of SS+PIBS vs SS-Only 2) IO-AMC vs. AMC Smulatons: In ths secton, IO-AMC s compared to an AMC system contanng only Sporadc Servers under dfferent mxed-crtcalty scenaros. Fgure 8 shows the response tme analyss and smulaton results whenlo-crtcalty tasks do not run n thehi-crtcalty mode. Smlar to Fgure 7, AMC-rtb outperforms IO-AMCrtb. Ths s due to the fact that AMC-rtb s an extenson of the tradtonal response tme analyss and does not experence the extra nterference caused by PIBS. y, we measured the weghted schedulablty [12], whch s defned as follows: W y p)= τ uτ) S y τ,p))/ τ uτ) where S y τ,p) s the bnary result 0 or 1) of the schedulablty test y on task set τ, and uτ) s the total utlzaton. The weghted schedulablty compresses a three-dmensonal plot to two dmensons and places hgher value on task sets wth hgher utlzaton. Fgures 9, 10, and 11 show the results of varyng the probablty of a HI-crtcalty task, the crtcalty factor and the number of tasks respectvely. In all scenaros,lo-crtcalty tasks do not run n the HI-crtcalty mode. As expected, the percentage of schedulable tasks for IO-AMC s slghtly lower than the percentage for tradtonal AMC. Ths s agan due to the slghtly larger nterference caused by a PIBS. Weghted Schedulablty 100 % 80 % 60 % 40 % 20 % AMC UB-H IO-AMC UB-H AMC-rtb IO-AMC-rtb 0 % Percentage of Tasks wth Hgh Crtcalty Fg. 9: Weghted Schedulablty vs % of HI-crtcalty Tasks 100 % 100 % Schedulable Task Sets 80 % 60 % 40 % 20 % AMC UB-H IO-AMC UB-H AMC-rtb IO-AMC-rtb IO-AMC-sm AMC-sm 0 % Utlzaton Fg. 8: Schedulablty of IO-AMC vs AMC Weghted Schedulablty 80 % 60 % 40 % 20 % 0 % AMC UB-H IO-AMC UB-H AMC-rtb IO-AMC-rtb Crtcalty Factor We also vared task set parameters to dentfy ther effects on schedulablty. For each set of parameters p n a gven test Fg. 10: Weghted Schedulablty vs Crtcalty Factor 10

11 Weghted Schedulablty 100 % 80 % 60 % 40 % 20 % AMC UB-H IO-AMC UB-H AMC-rtb IO-AMC-rtb 0 % Number of tasks Fgure 12. For SS+PIBS, each applcaton completed ts jobs at regular ntervals. However, for SS-Only, the HI-crtcalty server for nterrupts from the USB camera caused nterference wth the applcaton tasks. Ths led to the HI-crtcalty task depletng ts budget before fnshng ts job. Ths s due to the extra overhead added by a Sporadc Server handlng the nterrupt bottom half thread. Therefore, the system had to swtch nto the HI-crtcalty mode to ensure the HI-crtcalty task completed ts job, sacrfcng the performance of the LOcrtcalty task. Ths s depcted by the larger tme between completed jobs n Fgure 12. The SS+PIBS task set dd not suffer from ths problem due to the lower schedulng overhead caused by PIBS. Fg. 11: Weghted Schedulablty vs Number of Tasks B. Quest Experments The above smulaton results do not capture the practcal costs of a system of servers for tasks and nterrupt bottom halves. Ths secton nvestgates the performance of our IO- AMC polcy n the Quest real-tme system. We also study the effects of mode changes on I/O throughput for an applcaton that collects streamng camera data. All experments were run on a 3.10 GHz Intel R Core CPU. 1) Schedulng Overhead: We studed the schedulng overheads for two dfferent system mplementatons n Quest. In the frst system, Sporadc Servers were used for both tasks and bottom halves SS-Only). In the second system, Sporadc Servers were used for tasks, and PIBS were used to handle nterrupt bottom halves SS+PIBS). In both cases, a task set conssted of two applcaton threads of dfferent crtcalty levels assgned to two dfferent Sporadc Servers, and one bottom half handler for nterrupts from a USB camera. The frst applcaton thread read all the data avalable from the camera n a non-blockng manner and then busy-wated for ts entre budget to smulate the tme to process the data. The second applcaton thread smply busy-wated for ts entre budget, to smulate a CPU-bound task wthout any I/O requests. Both applcaton threads conssted of a sequence of jobs. Each job was released once every server perod or mmedately after the completon of the prevous job, dependng on whch was later. The expermental parameters are shown n Table II. Task C LO) or U LO) C HI) or U HI) T Applcaton 1 HI-crtcalty) 23ms 40ms 100ms Applcaton 2 LO-crtcalty) 10ms 1ms 100ms Bottom Half PIBS) U LO) = 1% U HI) = 2% 100ms Bottom Half SS) 1ms 2ms 100ms TABLE II: Quest Task Set Parameters for Schedulng Overhead The processor s tmestamp counter was recorded when each applcaton fnshed ts current job. Results are shown n Server Type HI-Crtcalty Task SS+PIBS) LO-Crtcalty Task SS+PIBS) HI-Crtcalty SS-Only) LO-Crtcalty SS-Only) Tme seconds) Fg. 12: Job Completon Tmes for SS+PIBS vs SS-Only Fgure 13 shows the addtonal overhead caused when Sporadc Servers are used for bottom half threads as opposed to PIBS. Ths hgher schedulng overhead s the cause for the mode change n the prevous experment. Fgure 13 depcts two dfferent system confguratons, one nvolvng only a sngle camera and another nvolvng two cameras. For each confguraton, the schedulng overhead for both SS-Only and SS+PIBS was measured. For the sngle camera confguraton, there s one HI-crtcalty task, one LO-crtcalty task, and one HI-crtcalty server ether PIBS or Sporadc Server) for the USB camera nterrupt bottom half thread. The schedulng overhead for SS-Only s more erratc and hgher than the system of Sporadc Servers and PIBS. The second confguraton adds a LO-crtcalty camera wth a 2% utlzaton n the LOcrtcalty mode, a 1% utlzaton n the HI-crtcalty mode, and a perod of 100 mcroseconds when utlzng a Sporadc Server. Fgure 13 shows that the schedulng overhead for an SS-Only system more than doubled, gong from an average of 0.21% to 0.49%, whle an SS+PIBS system experenced only a small ncrease of 0.03%. 2) Mode Change for I/O Devce: As mentoned n Secton IV, assgnng crtcalty levels to bottom half nterrupt handlers s akn to assgnng crtcalty levels to the devce assocated wth the bottom half. To test ths asserton, two USB cameras were assgned dfferent crtcalty levels and a mode change was caused durng the executon of the task set. The task set conssted of two Sporadc Servers and two PIBS, as shown n Table III. 11

12 CPU % SS-Only 2 Camera) SS-Only 1 Camera) SS+PIBS 2 Camera) SS+PIBS 1 Camera) Tme seconds) Fg. 13: Schedulng Overheads for SS-Only vs SS+PIBS Task C LO) or U LO) C HI) or U HI) T Applcaton 1 HI-crtcalty) 25ms 40ms 100ms Applcaton 2 LO-crtcalty) 25ms 24ms 100ms Camera 1 PIBS HI-crtcalty) U LO) = 0.1% U HI) = 1% 100ms Camera 2 PIBS LO-crtcalty) U LO) = 1% U HI) = 0.1% 100ms TABLE III: Quest Task Set Parameters for I/O Devce Mode Change Fgure 14 shows the camera data avalable at each data pont. At approxmately 30 seconds, a mode change occurs that causes Camera 1 to change from a utlzaton of 0.1% to 1%, thereby ncreasng the amount of data receved. Also at the tme of the mode change, Camera 2 s utlzaton swtches from 1% to 0.1%, causng a drop n receved data. The varance for Camera 1 after the mode change s due to extra processng of the delayed data that s performed by the bottom half nterrupt handler. Fnally, Fgure 15 shows the total data processed from each camera over tme. Bytes Read Camera 1 Camera Tme seconds) Fg. 14: Data From HI- and LO-crtcalty USB Cameras VII. RELATED WORK The most relevant related work has already been mentoned n Sectons II and III. Ths secton dscusses addtonal work n the areas of mxed-crtcalty and I/O-aware schedulng. Total Bytes Read 7x10 6 6x10 6 5x10 6 4x10 6 3x10 6 2x10 6 1x10 6 Camera 1 Camera Tme seconds) Fg. 15: Total Data Processed Over Tme In recent years, there have been many extensons to the Adaptve Mxed-Crtcalty model. For sngle core schedulng, Barauh, Burns and Davs extended ther orgnal AMC model to allow prortes to change [13]. Burns and Davs also ntroduced AMC-NPR Non-Preemptve Regon), whch mproved schedulablty by permttng tasks to have a fnal non-preemptve regon at the end of a job [14]. Flemng and Burns extended the AMC model to allow more than two crtcalty levels [15]. These varatons on the mxed-crtcal model could be ncorporated nto the IO-AMC model. L and Barauh [16] combned the EDF-VD [17] snglecore mxed-crtcalty approach wth fpedf [18], to develop a mult-core mxed-crtcalty schedulng algorthm. Pathan also developed a mult-core fxed prorty schedulng algorthm for mxed-crtcalty [19]. The approach adapted the orgnal sngle-core AMC approach to a mult-core schedulng framework compatble wth Audsley s algorthm [9]. The work by Pathan s more lkely to be easly ncorporated wth the IO- AMC model gven that both approaches use fxed-prortes. Ths work addresses the schedulng of and accountng of I/O events. Lewandowsk et al. [20] nvestgated the use of sporadc servers to approprately budget bottom half threads, as part of an Ethernet NIC devce drver. Zhang and West developed a process-aware nterrupt schedulng and accountablty scheme n Lnux, to ntegrate the management of tasks and I/O events [21]. A smlar approach was also mplemented n the LITMUS kernel for GPGPUs on multprocessor systems [22]. VIII. CONCLUSIONS Ths paper bulds on our schedulng framework n the Quest real-tme operatng system, comprsng a collecton of Sporadc Servers for tasks and Prorty Inhertance Bandwdth- Preservng Servers PIBS) for nterrupt handlers. We frst show a response tme analyss for a collecton of Sporadc Servers and PIBS n a system wthout mxed crtcalty levels. We then extend the analyss to support an I/O Adaptve Mxed- Crtcalty IO-AMC) model n a system comprsng of tasks and nterrupt handlers. Our IO-AMC response tme bound consders a mode change to hgh-crtcalty when nsuffcent resources exst for ether hgh-crtcalty tasks or nterrupt handlers n low-crtcalty mode. The analyss consders the nterference from low-crtcalty tasks and nterrupt handlers before the mode change. 12

13 Smulaton results show that a system of only Sporadc Servers for both tasks and nterrupt handlers has a hgher theoretcal number of schedulable task sets. However, n practce, usng PIBS to handle nterrupts s shown to be superor because of lower system overheads. Ths paper also shows expermental results n the Quest real-tme operatng system, where crtcalty levels are assgned to devces. Ths enables hgh crtcalty devces to gan more computatonal tme when nsuffcent resources exst to servce both hgh and low crtcalty tasks and nterrupt bottom halves. In turn, ths enables hgh crtcalty tasks that ssue I/O requests to be granted more CPU tme to meet ther deadlnes. The analyss n ths paper assumes that tasks and I/O bottom half nterrupt handlers are executed on separate servers that are ndependent of one another. In practce, a task may be blocked from executon untl a pendng I/O request s completed. As long as the I/O request s handled wthn the tme that a task s watng for ts server to have ts budget replenshed, and s therefore nelgble to run, then our analyss holds. Future work wll consder more complex task models where I/O requests can lead to blockng delays that mpact the executon of tasks. REFERENCES [1] S. Vestal, Preemptve schedulng of mult-crtcalty systems wth varyng degrees of executon tme assurance, n Real-Tme Systems Symposum, RTSS th IEEE Internatonal, pp , IEEE, [2] S. K. Baruah, A. Burns, and R. I. Davs, Response-tme analyss for mxed crtcalty systems, n Real-Tme Systems Symposum RTSS), 2011 IEEE 32nd, pp , IEEE, [3] Quest. [4] Y. L, R. West, and E. Mssmer, A vrtualzed separaton kernel for mxed crtcalty systems, n Proceedngs of the 10th ACM SIG- PLAN/SIGOPS nternatonal conference on Vrtual executon envronments, pp , ACM, [5] M. Dansh, Y. L, and R. West, Vrtual-CPU schedulng n the Quest operatng system, n Real-Tme and Embedded Technology and Applcatons Symposum RTAS), th IEEE, pp , IEEE, [6] B. Sprunt, Aperodc task schedulng for real-tme systems. PhD thess, Carnege Mellon Unversty, [7] C. L. Lu and J. W. Layland, Schedulng algorthms for multprogrammng n a hard-real-tme envronment, Journal of the ACM JACM), vol. 20, no. 1, pp , [8] M. Stanovch, T. P. Baker, A.-I. Wang, and M. G. Harbour, Defects of the posx sporadc server and how to correct them, n Real-Tme and Embedded Technology and Applcatons Symposum RTAS), th IEEE, pp , IEEE, [9] N. C. Audsley, On prorty assgnment n fxed prorty schedulng, Informaton Processng Letters, vol. 79, no. 1, pp , [10] A. Burns and S. Baruah, Towards a more practcal model for mxed crtcalty systems, n Workshop on Mxed-Crtcalty Systems colocated wth RTSS), [11] E. Bn and G. C. Buttazzo, Measurng the performance of schedulablty tests, Journal of Real-Tme Systems, vol. 30, no. 1 2, pp , [12] A. Baston, B. Brandenburg, and J. Anderson, Cache-related preempton and mgraton delays: Emprcal approxmaton and mpact on schedulablty, Proceedngs of OSPERT, pp , [13] S. Baruah, A. Burns, and R. Davs, An extended fxed prorty scheme for mxed crtcalty systems, Proc. ReTMCS, RTCSA, pp , [14] A. Burns and R. Davs, Adaptve mxed crtcalty schedulng wth deferred preempton, n Real-Tme Systems Symposum RTSS), 2014 IEEE, pp , IEEE, [15] T. Flemng and A. Burns, Extendng mxed crtcalty schedulng, n Workshop on Mxed-Crtcalty Systems colocated wth RTSS), [16] H. L and S. Baruah, Global mxed-crtcalty schedulng on multprocessors, n Proceedngs of the th Euromcro Conference on Real-Tme Systems, ECRTS, vol. 12, [17] S. K. Baruah, V. Bonfac, G. DAngelo, A. Marchett-Spaccamela, S. Van Der Ster, and L. Stouge, Mxed-crtcalty schedulng of sporadc task systems, n Algorthms ESA 2011, pp , Sprnger, [18] S. K. Baruah, Optmal utlzaton bounds for the fxed-prorty schedulng of perodc task systems on dentcal multprocessors, Computers, IEEE Transactons on, vol. 53, no. 6, pp , [19] R. M. Pathan, Schedulablty analyss of mxed-crtcalty systems on multprocessors, n Real-Tme Systems ECRTS), th Euromcro Conference on, pp , IEEE, [20] M. Lewandowsk, M. J. Stanovch, T. P. Baker, K. Gopalan, and A.- I. Wang, Modelng devce drver effects n real-tme schedulablty analyss: Study of a network drver, n Real Tme and Embedded Technology and Applcatons Symposum, RTAS th IEEE, pp , IEEE, [21] Y. Zhang and R. West, Process-aware nterrupt schedulng and accountng, n Real-Tme Systems Symposum, RTSS th IEEE Internatonal, pp , IEEE, [22] G. A. Ellott and J. H. Anderson, Robust real-tme multprocessor nterrupt handlng motvated by gpus, n Real-Tme Systems ECRTS), th Euromcro Conference on, pp , IEEE,