Operating System Support for MultimediaApplications and Processor Capacity Reserves

Haris Memeti (hm22459@seeu.edu.mk)Betim Cico (b.cico@seeu.edu.mk)

South Eastern European University, 2013

Abstract

Multimedia applications havetiming requirements that cannotgenerally be satisfied using thetime-sharing schedulingalgorithms of general purposeoperating systems. Our approachis to provide the predictability ofreal-time systems while retainingthe flexibility of a time-sharingsystem. We designed a processorcapacity reservation mechanismthat isolates programs from thetiming and executioncharacteristics of other programsin the same way that a memoryprotection system isolates themfrom outside memory accesses. Inthis paper, we describe ascheduling framework thatsupports reservation andadmission control, and weintroduce a novel reserveabstraction, specifically designedfor the microkernel architecture,for measuring and controllingprocessor usage. We haveimplemented processor capacityreserves in Real-Time Mach, andwe describe the performance ofour system on several types ofapplications.

1 Introduction

Multimedia applicationsrequire that operatingsystems support time-constrained data types suchas digital audio and videoin a responsive andpredictable way. Thegeneral purpose resourcemanagement policies foundin most operating systemsare incompatible with thesestrenuous timingconstraints, andtraditional real-timesystems are also poorlymatched to the multimediaapplication environmentsince user demands dictatea dynamically changing mixof both real-time and non-real-time activities. More-over, supporting commercial“shrink-wrapped” real-timemultimedia software has theadditional requirement thatthe operating system mustprovide a sensibleframework for controllingand communicatingresource usage amongindependent real-timeactivities.

1.1 Our solution

We have designed aprocessor capacity reservation

mechanism which allows theuser to control theallocation of processorcycles among programs. Themodel supports both real-time and non-real-timeactivities. Applicationsrequest processor capacityreservations, and once areservation has beengranted by the scheduler,the application is assuredof the availability ofprocessor capacity.Applications are also freeto increase theirreservations at any timeduring execution (subjectto the availability ofadditional resources), andthey are always free todecrease theirreservations. This designcombines the predictabilityof reservations with theflexibility of dynamicallyadjusting reservationlevels to accommodate achanging application mix orchanging timingrequirements withinapplications.A new kernel

abstraction, called areserve, tracks thereservation and measuresthe processor usage ofeach pro-gram. Thescheduler utilizes theseusage measurements toenforce reservations,

ensuring that programscannot monopolizecomputational resources.Additionally, reservesmay be passed acrossprotection boundariesduring IPC calls. This isespecially important inmicrokernel systems whichemploy separatelyscheduled servers toprovide various systemservices, andconsequently, the trueprocessor usage of aprogram includes theprocessor usage of theservers invoked by thatprogram.

Our reservation systemwas designed to supporthigher-level resourcemanagement policies. Forexample, a quality ofservice (QOS) manager coulduse the reservation sys-temas a mechanism forcontrolling the resourcesallocated to variousapplications. The QOSmanager would trans-latethe QOS parameters ofapplications to systemresource requirements(including processorrequirements), possiblywith the cooperation of theapplication itself. Themanager would then be ableto reserve the resourcesfor each pro-

1

gram, and it could use performancefeedback or interactive user input tochange the reservations for variousapplica-tions under its control.

Thus we have introduced a usefulstructure that divides the problem ofscheduling based on QOS requirements intotwo parts: a policy for allocating systemresources based on application-level QOSrequirements, and an abstrac-tion andmechanism for scheduling and controllingthose resources. Our model of processorcapacity reserves pro-vides thisabstraction and mechanism.

1.2 Current state of the art

Operating system support for digitalaudio and video typically includesonly primitive scheduling support forcontinuous media programs. Thissupport usually comes in the form of afixed-priority extension to a time-sharing scheduler. Continuous mediaapplications can then run at thehighest priority without interferencefrom non-time-constrainedapplications. However, such anarrangement does not protect high-priority applications from interfer-ence due to interrupt processing orfrom interference due to other high-priority applications. Having programsmake reservations for theircomputational requirements allows thescheduler to decide whether they canbe scheduled suc-cessfully and thuswhether a new reservation request canbe accepted. A program which has itsreservation request refused is free tomodify its timing constraints andrequest service at a lower rate or torequest (through some higher-levelserver) an adjustment of capacityusage by other pro-grams.

The possibility of persistentprocessor overload presents additionalproblems for current operating systems.

Simple fixed-priority scheduling doesnot help to detect or prevent potentialoverload conditions. Attempting toexecute two continuous mediaapplications which overload the systemresults in neither of the programs beingable to meet its timing constraints.Under a reservation scheme, the sys-temwould admit only one of the programs,and the other program could change itstiming parameters and request serviceunder the new parameters. A dynamicreserva-tion strategy prevents overloadby refusing to admit new programs whichwould result in an overloaded processor.

1.3 The rest of this paper

In the rest of the paper, we describeour model of pro-cessor capacityreserves more detail. We discuss ourreser-vation strategy in Section 2, andin Section 3 we explore issues inadmission control and scheduling withreserva-tions. Section 4 describes thenew reserve abstraction and discussesusage measurement and reservationenforcement. In Section 5, we present aperformance evaluation which

illustrates the behavior of severalkinds of programs that usereservations. Sections 6 and 7 discussfuture work and related work, and wemake a few concluding remarks inSection 8.

2 Our reservation strategy

The previous section motivated thedesign of a processor capacityreservation system. Here we examinethe mecha-nisms which are necessary toenable this type of resourcemanagement. The reservation strategymust:

1.provide some means for applicationprograms to spec-ify theirprocessor requirements,

2.evaluate the processor requirementsof new programs to decide whetherto admit them or not,

3.schedule programs consistently withthe admission control policy, and

4.accurately measure the computationtime consumed by each program toensure that programs do not over-run their reservations.

In the following sections, we example each of these points in more detail.

2.1 Capacity specification

The first requirement depends on aconsistent scheduling model that canaccommodate different kinds of programtiming requirements. For example, anaudio application might be scheduledevery 50 ms to generate an audio buffer.Many programs have no time constraintsat all and run as fast as possible foras long as the computation takes.Processor percentage provides astraightforward measure to describe theprocessor requirement of both of thesekinds of programs. Processor percentageis the processor time required by aprogram during an interval divided bythe real time of the interval, and theprocessor percentage consumed by aprogram over time defines its rate ofprogress.

Periodic programs (which executerepeatedly at a fixed interval) have anatural rate described by their periodand the computation time required duringeach period, assum-ing the computationtime is fairly constant. When thecomputation time is not constant, aconservative worst case estimatereserves the necessary processorcapacity, and the unused time isavailable for background processing.Pro-grams that are not periodic have nonatural computing rate, but we canassign them a rate. This rate willdetermine the duration of time until theprogram completes, and the rate must bereserved based on the delay requirementsof

2

Reservation period

τ

Computation time

Figure 1: Periodic Framework

the program.Figure 1illustrates thecomputationalrequire-ment ofa periodicprogram . Withthis kind offramework, wecan useschedulingalgorithms whichscheduleprogramsaccording totheir allocatedrate.

2.2 Admissioncontrol

The secondrequirement, thatthe scheduler caneval-uate thetimingconstraints ofnew programsagainst theavailablecapacity, callsfor a schedulingframework thattranslates theprocessorrequirementsspecified byindivid-ual

programs intoutilizationmeasures whichcan be used inan admissioncontrol policy.We shall seethat simply sum-ming theindividualutilizations ofall executingprograms willwork under adynamic priorityschedulingdiscipline, butthere aredrawbacks tothis approach.Another approachis fixedpriorityscheduling withan appropriatepriority as-signment, butthis method doesnot, in general,allow us toreserve the full100% of theprocessor.

2.3 Scheduling

The thirdrequirement,that thescheduling

policy sched-uleprograms in a waythat isconsistent withthe admissioncontrol policy,reflects the factthat thescheduling frame-work must beconsistent acrossall of theresource manage-ment policies inthe system. Ifthe schedulingpolicy does notsupport theassumptions madeby the admissioncontrol policyabout howprograms areordered forexecution, thereservationsystem will failto operateproperly.

2.4 Reservationenforcement

The fourthrequirement, thatthe scheduleraccuratelymeasure usage andenforcereservations,demands preciseperformancemonitoringsoftware whichtypical operatingsystems do notprovide.

Operatingsystems usuallyaccu-mulateusage statisticsfor each processby samplingduring regularclock interrupts[7], but thisinformation isim-precise overshort intervals.Furthermore, theexecutionbehavior of themonitoredprogram must beindependent

Of the samplingperiod. Moreprecisemechanismmeasuresdurationsbetween contextswitches andaccounts forinterruptprocessing timeand other systemoverhead.

Even if thesystem canaccuratelymeasure capacitycon-sumption on aper-processbasis, otherproblems arise.Us-age statisticsin traditionaloperating systemsconsist ofsystem-levelusage time anduser-level timefor each pro-cess. Formonolithicoperatingsystems, thisapproach issufficient, butfor microkernelsystems whereoperating sys-temservices areoffered bydifferent user-level servers[4], the usagestatistics of anactivity cannotbe found in theusage statistics

of a singleprocess. Anactivity mayinvoke separateoperating systemservers toperformfilesystem ac-cess,networking,naming, etc. Tomaintain anaccurate pictureof an activity’scapacityconsumption, thecost of theseservices must becharged to theactivity itselfrather than tothe individualservers. Thus,capacityreserves must bemaintainedindependentlyfrom anyparticularthread ofexecution sothat work doneby any processor thread on be-half of thereservedactivity can becharged to thatactivity. Thisis accomplishedsimply bycreating anindependentreserveabstractionwhich may bebounddynamically todifferent

threads ofexecution.With accurate

usagemeasurements anda mechanism togenerate ascheduling eventwhen a programattempts tooverrun itscapacityreservation, thescheduler cancontrol theexecution ofprograms andprevent them forinterfering withotherreservations.

3 Admission control and scheduling

A schedulingframework basedon the rate ofprogram progressprovides aneffective

environment forimplement-ingprocessorreservation. Wecan associaterates withperiodic andnon-periodicprograms asdescribed in theprevioussection. Therate of aperiodic programcan bedetermined fromthe period thatthe programmerhas in mind andthe computationtime during thatperiod. For non-periodicprograms, therate arises fromdelay require-ments. In eithercase, the ratealone does notfully specifythe timingattributes of aprogram; thecomputation time

3

and period are essential.For example, a program could specify

that it requires 30% of the processortime to run successfully on a givenmachine (processor reservation isunavoidably machine-dependent). But nowthe question is how to measure the 30%.Does the program require 30 milliseconds(ms) out of 100 ms? Or would 300 ms outof 1000 ms be sufficient? These twopossibilities are very different: aprogram that is designed to output avideo stream at 10 frames per secondneeds 30 ms out of 100 ms, and 300 ms atthe end of each 1000 ms period is notsufficient to meet the timingrequirements of each 30 ms burst ofcomputation. On the other hand, a 60-second program compilation that requests30% of the processor does not need tohave its computation time spread out with30 ms every 100 ms, incurring muchcontext-switching overhead; in this case300 ms every 1000 ms would suffice.

Thus, we have three values whichdescribe the processor requirement fora program, and two of these arerequired to specify a processorpercentage. Let be the processorpercentage, C be the computation time,and T be the pe-riod of real time overwhich the computation time is to beconsumed. Then we have

= CT :

We generally specify processorrequirements using and T since is sucha natural expression of processorreservation and since we think of mostperiodic activities in terms of theperiod T .The computation time C of a periodic

activity is difficult for theprogrammer to measure accurately, soour approach is to have the programmer

estimate the computation time and thendepend on the system to measure thecomputation time and provide feedbackso that the estimate can be ad-justedif necessary. For non-periodicactivities that are to be limited by aprocessor percentage, C does notcorrespond to the code structure, sospecifying and T defines how far thecomputation can proceed beforeconsuming its share of the processorfor each interval. This is in contrastto periodic activities which wouldgenerally associate a code block withthe computation that is to repeatduring each period.Delay for a non-periodic program

which executes at a given rate can becalculated from the rate of executionand the total execution time. Aprogram that runs at rate with totalcomputation time (service time) S willtake

D = S

time to complete execution. Thisequation can also be used to derive asuitable rate given the totalcomputation time

and largest acceptable delay. Usingthe largest acceptable delay yieldsthe smallest acceptable rate ofexecution.We now consider how to go about

scheduling programs assuming we candetermine the scheduling parameters ,C, and T that specify the timingrequirements of each pro-gram. Fixedpriority scheduling is a practical policywhich provides a method of assigningpriorities that supports pro-cessorreservation and admission control.Dynamic priority scheduling, such asearliest deadline scheduling, is anotherpractical method that also supportsreservation and admis-sion control.

3.1 Admission control under fixedpriority scheduling

Using fixed priority scheduling in ourframework re-quires a method of assigningpriorities to programs which ensures thateach program will progress at itsassigned rate. The rate monotonic (RM)priority assignment of Liu and Layland[9] does just that. Under this regime,the highest priority is assigned to thehighest frequency program and the lowestpriority is assigned to the lowestfrequency pro-gram. The rate monotonicscheduling analysis also gives us a basisfor a processor reservation admissionpolicy.Let n be the number of periodic

programs and denote the computationtime and period of program i by Ci andTi, respectively. Liu and Layland

proved that all of the pro-grams willsuccessfully meet their deadlines andcompute at their associated rates if

n

XCi n(21=n , 1):i=1

Ti

When n is large, n(21=n , 1) = ln 2 ':69. This bound is pessimistic: it ispossible for programs which do notsatisfy the inequality to successfullymeet their deadlines, but we cannotdetermine this from the Liu and Laylandanalysis.

An admission control policy followsnaturally from this analysis. To keeptrack of the current reservations, wemust remember the rates of the programswhich have reserved computation time,and the total reservation is the sum ofthese rates. A simple admission controlpolicy is to admit a new program if thesum of its rate and the total previousreservation is less than :69. Such apolicy would leave a lot of computationtime which could not be reserved. Onepossibility is to use that time forunreserved background computations.Another possibility is to use the exactanal-ysis of Lehoczky et al. [8] todetermine whether a specific collectionof programs can be scheduledsuccessfully, al-though the exactanalysis is more expensive than thesimple, pessimistic analysis above. Intheir work, Lehoczky et al. also gave anaverage case analysis showing that onaverage, task sets can be scheduled upto 88% utilization. So in most

4

cases, this unreservable computationtime is only 10-12% rather than 31%.We note that the rate monotonic

scheduling algorithm was analyzedunder simplifying conditions. Liu andLay-land [9] made the followingassumptions to enable their analysis:

1.programs are periodic, and thecomputation during one period mustfinish by the end of the period(its deadline) to allow the nextcomputation to start,

2.the computation time of eachprogram during each period isconstant,

3.programs are preemptive with zerocontext switch time, and

4.programs are independent, i.e.programs do not syn-chronize orcommunicate with other programs.

Subsequent work focused on ways to relax these assump-tions [10, 11].

3.2 Admission control under dynamicpriority scheduling

The earliest deadline (ED) schedulingpolicy, a dynamic priority policy, iseffective for scheduling periodic pro-grams such as our continuous mediaprograms. We define the deadline of acomputation to be the end of the periodin which it started, and the earliestdeadline policy chooses, at a givenpoint in time, the program which has thesmallest deadline value. Liu and Layland[9] showed that, under the sameassumptions outlined in the section onrate mono-tonic scheduling, all programswill successfully meet their deadlinesunder earliest deadline scheduling if

n

XCi 1:

i=1 Ti

The admission control policy thatarises from this anal-ysis is similarto the RM strategy. We record thereserved rates of programs that havebeen admitted, and the totalreservation is the sum of these rates.Admission control uses this sum todetermine whether adding the rate ofthe new program would result in a sumless than 100%, and, if so, theprogram is admitted. If not, thereservation cannot be granted.

3.3 Discussion

Earliest deadline scheduling seemspreferable to the rate monotonicscheduling since ED allows the admissioncon-trol policy to reserve up to 100% ofthe processor whereas

RM can only guarantee reservations up to69%. As men-tioned previously, the 69%bound for RM is pessimistic, and in mostcases, 88% is a more realistic bound. Infact, the reservation bound of ratemonotonic is 100% for the special casewhere all periods are harmonic, i.e. eachperiod is an even multiple of everyperiod of smaller duration. Addi-tionally, an amount of unreservedcomputation time of per-haps 5-10% may benecessary to avoid scheduling failuresdue to inaccuracy in the computation timemeasurement and enforcement mechanismsand due to the effects of crit-icalregions and other synchronization andcommunication among programs. So eitherof the scheduling algorithms would beappropriate for reservation scheduling.

4 Reservation enforcement and reserves

Our reservation scheme depends on anenforcement mechanism to make sure thatprograms do not exceed their processorreservations. The main goal is to ensureshort-term adherence to the reservationwith the realization that perfectenforcement is impossible due tosynchronization and communication amongprograms. We also require that thecomputation time of operating systemservices provided by user-level serversin a microkernel architecture be ac-counted for and included in thereservation consumption.

4.1 Measurement and controlaccuracy

Our enforcement mechanism monitorsprocessor usage by measuring the timeeach program is executing on theprocessor, and it charges thiscomputation time against the reserveassociated with the program. The reservecontains the duration of computationtime accumulated in the current period,and the scheduler puts the program in atime-sharing mode when its reservationhas been consumed. Programs which havenot yet consumed their reservation takeprece-dence over unreserved programs,but if there is unreserved processortime available, unreserved programs cantake advantage of the extra processortime. Even though the timestampmonitoring method yields an accuratemeasure of the processor usage, it isnot always possible for the scheduler topreempt a running program at anarbitrary point in time. For example, ifa computation is in the (non-preemptive)kernel or in a critical region when itoverruns its reservation, it cannot besummarily truncated, although thescheduler can easily penalize theprogram in its next period based on theduration of the violation.

4.2 Microkernel accounting

In many operating systems, the processor usage for each process is recorded in a per process logical clock,and the

5

User UserP

A E S1 P S2C

A EB C D

B D

B* D**

B** D*

Monolithic KernelMicrokerne

l

(a) (b)

Figure 2: Microkernel Accounting

logical clock isusually dividedbetween user timeand sys-tem time[7]. Thecombination ofthese two values isan accurate long-term measure of thecomputation timeused by theprocess. In amonolithic system,this is the end ofthe story, but in amulti-threadedmicrokernelarchitec-ture, perthread user andsystem times aremeaningless. If athread invokesvarious user-levelservers foroperating systemservices, thecomputation timeconsumed by theoverall activity is

not reflected inthe user and systemtime of the singleclient thread. Thecomputation timefor that activityhas been charged tothe client threadand to the serverthreads as well.Thus, we require anaccountingmechanism thataccounts for thecomputation time ofan activity beingspread over acollection ofthreads.Figure 2

illustrates thedifference betweenaccounting inmonolithicoperating systemsand the accountingwe require formicrokernels. Part(a) shows aprogram in a

monolithic systemwhich does someprocessing of itsown and makes twosystem calls. Thearrows representthe control paths,and each labelrepresents thecomputation timerequired in theassociated controlpath. In thiscase, the totalusage of theprogram is P = A +B + C + D + E andthis time isdivided into auser time of PU =A+C +E and asystem time of PS= B + D.Part (b) of

Figure 2illustrates thecontrol path for asimilar program ina microkernelwhere the servicesrep-resented by Band D areperformed byseparate servers.The B and B labelscorrespond to thecomputation timefor the controlnecessary to issuethe serverrequests, andlikewise for D andD . In themonolithic systemac-countingscheme, the totalprogram usage ismeasured by thesystem to be P = A

+ B + C + D + Ewhere the

user usage is PU =A + C + E and thesystem usage is PS= B + D . Theactual servicetime is charged tothe servers S1 andS2 and is neveraccounted for inthe client’s usagemeasurements. Thesame control pathmeasured by ourmicrokernelaccounting schemefindsP = A + B + B + B +C + D + D + D + E,and this is theaccurate measure ofprocessor usage forprogram P.

4.3 Reserveabstraction

Our reserveabstraction servesthe purpose ofaccuratelyaccounting for anactivity whichinvokes user-levelservices offered bythe operatingsystem. Reservesare associated withprocessorreservations andserve the dualpurpose oforganizing thereservationparameters andfacilitating theenforcement of

reservations bymeasuring usageagainst thereservation. Eachthread has anassociated reserveto whichcomputation time ischarged. One ormore threads maycharge computationtime to the samereserve. The mostusefulconfiguration is toassociate areserve, along withits processorreservation, witheach “client”thread in thesystem. As thisclient invokesoperations onvarious servers,the IPC mechanismforwards theclient’s reserve tobe used by theserver thread tocharge itscomputation time onbehalf of theclient. The resultis that an accurateaccounting is madeof the resourcesconsumed by theclient threadthroughout thesystem.In addition to

reserves, we allowthreads to rununre-served intime-sharing mode.This makes itpossible to usethe unreserved

capacity or unusedreservations fortime-sharing or

backgroundprocessing.

6

Usag

1 Periodic thread

0.8

0.6

0.4

0.2

0

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5Time(s)

(a) No competition

Usag

1 Periodic thread

0.8

0.6

0.4

0.2

0

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5Time(s)

(b) With competition

Figure 3: Unreserved periodic thread without and with competition

5 Performance evaluation

We have implemented processorcapacity reserves in Real-Time Mach[12], and in this section, weillustrate the reservation system’sbehavior in various situations byshowing processor usagemeasurements for several differ-enttask sets. The test cases ran on aGateway2000 33MHz 486-based machinewith 16MB of RAM and an Alpha LogicSTAT! timer board for accuratetiming. We imple-mented reserves onversion MK78 of Real-Time Mach, andwe use CMU UNIX server versionUX39.

5.1 Unreserved periodic thread

The first test case, shown inFigure 3(a), shows the be-havior ofa single periodic thread executingwith no com-petition for theprocessor. The processor usage isfairly constant over time in thiscase. The thread runs its com-putation of 16 ms during eachperiod of 40 ms (40% uti-lization),and we take the processor usage

measurement for each period at theend of the period. The reservationof 40% is actually slightly higherthan the actual computa-tion timefor the thread; this is done toaccommodate slight variations incomputation time. The processorusage for a reservation period isthe processor time consumed duringthe period divided by the lengthof the period, and we plot ahorizontal line (at theappropriate usage level) from thebeginning to the end of theperiod. Thus, the graph is asequence of flat usage levels.

Figure 3(b) illustrates thebehavior of the periodic thread whenit competes with other threads forthe processor. There are five otherthreads in this case, but forsimplicity they are not shown in thefigure. All of the threads are

scheduled using the Mach time-sharing policy, including theperiodic thread. The thread’sprocessor usage is natu-rally quiteunpredictable. We note that afterthe periodic thread has beenprevented from executing for sometime, as is the case from time 2 totime 2:7 or so, the thread attemptsto catch up on all of the missedcomputation time. Thus, we have thesurge of “catch-up” activity fromtime 2:7 to time 3:2. This isclearly not the behavior we desirefor periodic threads.

5.2 Reserved periodic threads

In the next test case, theperiodic thread reserves theprocessor capacity it needs inadvance. So in Figure 4(a), we seethat the periodic thread behaves asif there were no competition, eventhough there are five additionalun-reserved threads (not shown)

competing for the processor. Theperiodic thread executes inreserved mode, and there-foreenjoys the processor capacity thatit needs to run.

Figure 4(b) shows the processorusage of two reserved threads whichare competing with five unreservedthreads. Periodic thread 1 reserves16 ms of computation time every 80ms (20% utilization), and Periodicthread 2 reserves 16 ms every 40 ms(40% utilization). Both reservedthreads can successfully achievetheir desired computation rates.

5.3 Server invocation with noreservation

In Figure 5, we show what happensif the reservation system does notcoordinate reservations duringremote pro-cedure call (RPC) typesof communication. The structure ofthe task set is shown in Figure5(a); reserved threads are drawnwith bold lines in the figure todistinguish them from

7

Usag

1 1

Periodic threadPeriodic thread 1

0.8 0.8Periodic thread 2

0.6 0.6

0.4

U s a g e

0.4

0.2 0.2

0 0

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5Time(s)

Time(s)

(a) One reservedthread

(b) Two reserved threads

Figure 4: Reserved periodic thread(s) with competition from unreserved threads

1 2 S

Usag

1

Periodic thread 1 0.8Periodic thread 2 Server thread

0.6

0.4

0.2

0

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5Time(s)

(a) Task set structure (b) Measured usage behavior

8

1 2 SUsag

(a) Task set structure

1

Periodic thread 1 0.8Periodic thread 2 Server thread

0.6

0.4

0.2

0

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5Time(s)

(b) Measured usagebehavior

Figure 6: Integrated client/server reserves

utilization. And now thecombined activity ofPeriodic thread 2 and itsserver execute at a constant40% combined usage. The linearound 2-3% gives the usageof the client, and the linearound 36% gives the usageof the server. Thus, bymanaging the reservationsappropriately across threadinteractions, we are able topreserve the isolationprovided by reserves forsystem activities whichcross thread bound-aries.

be used to charge the remoteservice. Another aspect ofreservation in distributedsystems concerns thereservation of protocolprocessing on each of thehosts. We are plan-ning touse the notion of a “suspensereserve” to charge theprotocol processing timeassociated with bringingpackets from the networkdevice to the end point ofthe communi-cation session.When the destination programof the packet is determined,the usage associated withthat packet can be charged tothe receiving program.

6 Future work

The processor reservationmechanism described in thispaper forms a basis for moresophisticated management ofsystem resources. Forexample, we envision areserved window system with

a window manager thatcontrols re-sourcereservations forapplications running underdifferent windows. The userinterface would be used todynamically change thereservations forapplications, depending onthe user’s preference or

focus.Toward this end, we plan

to provide reservation sup-port for system resourcesother that the processor,notably pages, pagingactivity, network buffers,and protocol pro-cessingactivity. Our position isthat most other resourcesare discrete and aretherefore easier to allocateand reserve than processorcycles, so we haveconcentrated mainly on theharder problem. We dorecognize, however, thatsome discrete resources,such as message buffers, aredifficult to reserve inadvance.

Processor capacity reservescan support reservation indistributed multimediasystems by having eachreserve contain reservationsfor various resources aroundthe dis-tributed system. Thenmessages containing requestsfor remote service willcontain these “sub-reserves”which can

7 Related work

Many researchers considerresource reservation desir-able if not absolutelynecessary for continuousmedia op-erating systems.Herrtwich [5] gives anargument for re-sourcereservation and carefulscheduling in these systems.Anderson et al. [2] giveadditional arguments forintroduc-ing moresophisticated timing andscheduling features intocontinuous media operatingsystems, and their DASH sys-tem design supportsreservation and uses earliestdeadline scheduling for real-time traffic. They useearliest deadline because itis optimal in the sense thatif a collection of tasks withdeadlines can be scheduled byany algorithm, it can bescheduled by the earliestdeadline algorithm. They donot explicitly describeexactly how processorreserva-tion is integratedwith network reservation orwhy earliest deadline is wellsuited to reservationstrategies. We demon-stratewhy rate monotonic schedulingand earliest deadlinescheduling are suitable forprocessor reservation, and wecompare these two approaches.In addition, we explain howreservations can be enforcedand how non-real-timeprograms can be integratedwith real-time programs inthe scheduling framework.

9

Jeffay et al. implemented a programmingmodel specif-ically designed forguaranteed real-time scheduling [6].This involves a restricted programmingmodel and an off-line analysis. Incontrast, our approach is to provideopti-mistic predictability using a moretraditional programming model and avery fast on-line analysis.Other work, particularly work

related to network com-munication,relies on reservation in network nodes(gate-ways and hosts) to supportbandwidth reservation and rate-basedprotocols [1, 3]. Our work provides abasis for software implementation ofthese kinds of protocols in thecontext of general purpose operatingsystems.

8 Conclusion

In this paper, we have motivated thedesign of a proces-sor reservationstrategy for supporting continuous mediaapplications. Our scheduling framework,based on compu-tation rates expressed ascomputation time per duration, providesan effective way to specify processorrequire-ments. Two scheduling algorithmswith slightly different properties aresuitable for implementing reservation inthis framework. The design addressespractical issues in im-plementation ofthe scheduling framework, and it dependson a novel reserve abstraction foraccurate computation time measurement andreservation enforcement. This ac-countingmechanism is well suited to themicrokernel archi-tecture; it tracksprocessor time used by individual threadswhich call on user-level servers toperform system services.Our prototype implementation using

Real-Time Mach 3.0 demonstrates thefeasibility of our approach and showsthat applications can achieve

predictable real-time perfor-manceusing our reservation mechanism.

Acknowledgements

The authors would like to expresstheir appreciation to the followingpeople for their comments andsuggestions: Brian Bershad, RagunathanRajkumar, Jim Zelenka, Raj Vaswani,John Zahorjan, and the members of theART group and Mach group at CMU.

References

[1] D. P. Anderson, R. G. Herrtwich,and C. Schae-fer. SRP: A ResourceReservation Protocol forGuaranteed-PerformanceCommunication in the In-ternet.Technical Report TR-90-006,International Computer ScienceInstitute, February 1990.

[2] D. P. Anderson, S. Tzou, R.Wahbe, R. Govindan, and M. Andrews.Support for Continuous Media in theDASH System. In Proceedings of the 10thInterna-tional Conference on DistributedComputing Systems, pages 54–61, May1990.

[3] D. Ferrari and D. C. Verma. AScheme for Real-Time ChannelEstablishment in Wide-Area Networks. IEEE Journal on Selected Areas inCommunication, 8(3):368–379, April1990.

[4] D. Golub, R. W. Dean, A. Forin,and R. F. Rashid. Unix as anApplication Program. In Proceedings ofSummer 1990 USENIX Conference, June1990.

[5] R. G. Herrtwich. The Role ofPerformance, Schedul-ing, andResource Reservation in MultimediaSys-tems. In A. Karshmer and J.Nehmer, editors, Oper-ating Systems ofthe 90s and Beyond, number 563 inLecture Notes in Computer Science,pages 279–284. Springer-Verlag,1991.

[6] K. Jeffay, D. L. Stone, and F.D. Smith. Kernel Sup-port for LiveDigital Audio and Video. ComputerCommunications (UK), 15(6):388–395,July-August 1992.

[7] S. J. Leffler, M. K. McKusick,M. J. Karels, and J. S. Quarterman.The Design and Implementation of the 4.3BSDUNIX Operating System. Addison-Wesley,1989.

[8] J. P. Lehoczky, L. Sha, and Y.Ding. The Rate Monotonic SchedulingAlgorithm: Exact Characteri-zationand Average Case Behavior. InProceedings of the 10th IEEE Real-TimeSystems Symposium, pages 166–171,December 1989.

[9] C. L. Liu and J. W. Layland.Scheduling Algorithms forMultiprogramming in a Hard RealTime Environ-ment. JACM, 20(1):46–61, 1973.

[10] L. Sha, R. Rajkumar, and J. P.Lehoczky. Priority InheritanceProtocols: An Approach to Real-TimeSynchronization. IEEE Transactions onComputers, 39(9):1175–1185,September 1990.

[11] B. Sprunt, L. Sha, and J. P.Lehoczky. Aperiodic Task Schedulingfor Hard Real-Time Systems. The Journalof Real-Time Systems, 1(1):27–60, June1989.

[12] H. Tokuda, T. Nakajima, and P.Rao. Real-Time Mach: Toward aPredictable Real-Time System. In Proceedings of USENIX Mach Workshop,October 1990.

10