Support ing Time-Sensit ive I nt roduct ion • Mult imedia applicat ions t ime-sensit ive Applicat ions on a Commodit y – Ex: periodic execut ion wit h low j it t er (e.g. sof t OS modem) – Ex: quick response t o ext ernal event (e.g. f rame capt ure in videoconf erence) • OS must allocat e r esour ces at appr opr iat e t imes A. Goel, L. Abeni, C. Krasic, J. Snow • Needs: and J. Walpole – High precision t iming f acilit y – Well-designed preempt ible kernel – Appropriat e scheduling Proceedings of USENI X 5t h Symposium • Most commodit y OSes don’t (Windows, Linux) on Operat ing Syst em Design and • Special OS enhancement s can suppor t r eal I mplement at ion (OSDI ) -t ime – But hard real-t ime, s.t . degradat ion of non-real-time December 2002 applicat ions suf f er Out line Approach • I nt roduct ion (done) 1) Firm t imers f or ef f icient , high-resolut ion • Relat ed Work (next ) t iming • Requirement s 2) Fine-grained kernel preempt ibilit y • I mplement at ion 3) Priorit y and Reservat ion–based CPU • Evaluat ion scheduling • I nt egrat e int o Linux kernel • Conclusions � Time-sensit ive Linux • Show benef it s real-t ime applicat ion, but not degrade perf ormance of ot her apps Relat ed Work Time-Sensit ive Requirement s • From t ime need t o handle event unt il act ual • I llust r at ion of r eal-t ime implement at ion dispat ch is ker nel lat ency dif f icult ies [6,15,16] • Mat hemat ical r eal-t ime scheduling [10,19] – But ignore pract ical issues such as non- preempt ibilit y • Pr act ical r eal-t ime scheduling [12,17,22] – But perf ormance of non -r eal -t ime suf f ers • Real-t ime micro-ker nelish [ 4] – But hard-t imers add more overhead • New OSes [ 9] • Need: Timing Mechanism , Responsive Ker nel , CPU – But dif f erent AP I so hard t o port apps Scheduling Algor it hm 1
Timer Mechanism Responsive Ker nel • Accur at e t imer t he lar gest add t o ker nel lat ency • Can use: – One-shot t imer –on x86, use on -chip C P U Advanced • I f t imer is accur at e, might st ill not have low P rogrammable I nt errupt Cont roller (AP I C). Needs ker nel lat ency if ker nel cannot r espond t o be reprogrammed each t ime. – (Tradit ionally, t hread in kernel runs unt il done) – Sof t Timer –check f or expired t imers at st rat egic • Solut ion: r educe size of non-pr eempt ible r egions locat ions, reduce t he number of int errupt s • Solut ion: Combine t o call f ir m t imer s CPU Scheduling Algorit hm Misc • Not e, any one alone not suf f icient ! – High-resolut ion t imer doesn’t help if kernel not pr eemt ible or: – Responsive ker nel not usef ul wit hout accurat e t ime • Not e, t asks may not be independent : – X server operat es (and is scheduled) in • Need t o schedule t he r ight pr ocess as quickly as FI FO order possible – Video applicat ion wit h higher priorit y t han X • Solut ions: server will have priorit y inversion (wait ing – P riorit y-based scheduler –pre-assign priorit ies and on low pr ior it y) (will addr ess) schedule in t hat order – P roport ion -period scheduler – schedule wit h an upper-bound on delay Per iodic Timer s Out line • Commodit y OSes implement t iming wit h per iodic • I nt roduct ion (done) t imer s. • Relat ed Work (done) – Ex: on I nt el x86, int errupt s generat ed wit h • Requirement s P rogrammable I nt erval Timer (P I T) (done) – Ex: is 10 ms on Linux, t hus is max lat ency • I mplement at ion • Can r educe lat ency by r educing per iod, but adds – Fir m Timer s (next ) mor e int er r upt over head • I nst ead, move t o one-shot t imer – Fine-Gr ained Pr eempt ibilit y • Ex: t wo t asks, period 5 and 7 ms, t imer period 1 – CPU Scheduling • Evaluat ion ms, 35 ms running t ime – P eriodic: 35 int errupt s generat ed • Conclusions – One-shot : 11 int errupt s generat ed (5, 7, 10, 14 … ) – P lus, one-shot t imer reduces t imer lat ency 2
Fir m Timer Design • One-shot t imer cost s: t imer r epr ogr amming and Firm Timer I mplement at ion f ielding t imer int er r upt s – Reprogramming cost has decreased in modern hardware (P 2+) • Timer queue f or each queue, sor t ed by expir y • P I T on x86 used t o use slow out on bus • When t imer expir es • Newer AP I C resides on CP U chip – execut e callback f unct ion f or each expired t imer – Thus, last cost is int errupt cost • Reduce by sof t-t imer s – Reprogram AP I C • Global over shoot value (but could be done per – P oll f or expired t imers at st rat egic point s where cont ext swit ch is occurring t imer) • Ex: syst em call, int errupt , except ion ret urn • Accessible t hr ough: nanosleep(), pause(), • Two new pr oblems: poll cost and added t imer lat ency setitimer(), select() and poll() • Can solve 2 nd pr oblem wit h t imer over shoot – P rovides upper bound on lat ency – Tradeof f bet ween accuracy and overhead • 0 � hard t imers, large � sof t -t imers • At 100 MHz, t heor et ical accur acy of 10 nanoseconds Out line Reasons Scheduler Cannot Run • I nt roduct ion (done) • I nt errupt s disabled • Relat ed Work (done) – Hopef ully, short • Requirement s (done) • Anot her t hread in crit ical region • I mplement at ion • Commodit y OSes have no preempt ion f or – Fir m Timer s (done) ent ire kernel period – Fine-Gr ained Pr eempt ibilit y (next ) – Ex: when int errupt f ires or durat ion of – CPU Scheduling syst em call • Evaluat ion – Unless known it will be long (ex: disk I / O) • Conclusions – Preempt ion lat ency under Linux can be 30 ms Out line Enabling More Preempt ion • I nt roduct ion (done) 1) Add more preempt ion point s • Relat ed Work (done) – Must be done manually • Requirement s (done) 2) Allow preempt ion anyt ime not using shared • I mplement at ion dat a st ruct ures – Fir m Timer s (done) – Prot ect shared st ruct ures wit h locks – Fine-Gr ained Pr eempt ibilit y (done) – Can st ill result in long lat encies – CPU Scheduling (next ) • Combine 1) and 2) works best • Evaluat ion – (Done by Rober t Love [11]) • Conclusions – (Aut hor s evalut ed in [1]) 3
P roport ion-Period CPU Scheduling CPU Scheduling • For single independent t asks, assign highest • Priorit y CPU scheduling is simple, POSI X priorit y t ask compliant – Mis-behaving t ask can consume “t oo much” – Use t emporal prot ect ion – But assumes applicat ions well-behaved • Pr opor t ion-per iod pr ovides by allocat ing f ixed CPU • So, combine wit h pr opor t ion-period on t op amount each per iod t o give prot ect ion – Task execut es as “real-t ime” (highest priorit y) f or t ime Q every T – P eriod det ermined by applicat ion requirement s (Ex: 30ms f or video) • I mplement ed using Ear liest Deadline Fir st (EDF) Priorit y CPU Scheduling Out line • Pr ior it y inver sion occur s when an applicat ion has • I nt roduct ion (done) mult iple t asks t hat ar e independent • Relat ed Work (done) – Example: Video applicat ion uses X • Requirement s (done) – Video is highest since t ime-sensit ive – Sends f rame t o X server and blocks • I mplement at ion (done) – X server may be preempt ed by ot her medium • Evaluat ion (next ) priorit y t ask, hence delaying Video client • Conclusions • To solve, use highest-locking pr ior it y (HLP) [19] in which t ask inher it s pr ior it y when using shar ed resource – Example: display is shared resource so X server get s highest priorit y of blocking client s Evaluat ion Lat ency in Micro Benchmarks • Test low-level component s of ker nel lat ency: 1) Behavior of t ime-sensit ive applicat ions r unning on TSL t imer , pr eempt ion and scheduling – Time-sensit ive process t hat sleeps f or a specif ied 2) The Over heads of TSL • Set up: amount of t ime (using nanosleep() ) – Result s: 10 ms in st andard Linux, f ew microseconds – Sof t ware in TSL • Linux 2.4.16 • Test pr eempt ion lat ency under loads • Robert Love’s lock-breaking preempt ible kernel pat ch • P – Result s: Linux worst case 100 ms (when copying dat a roport ion-period scheduler f rom kernel t o user space), but t ypically less t han – Hardware 10 ms and is hidden by t imer lat ency. TSL is 1 ms. • 1.5 GHz I nt el P4 wit h 512 MB RAM (Result det ails in [1]) 4
Recommend
More recommend
