of 46/46
Sporadic Server Scheduling in Linux Theory vs. Practice Mark Stanovich Theodore Baker Andy Wang

Sporadic Server Scheduling in Linux Theory vs. Practice Mark Stanovich Theodore Baker Andy Wang

  • View
    29

  • Download
    0

Embed Size (px)

DESCRIPTION

Sporadic Server Scheduling in Linux Theory vs. Practice Mark Stanovich Theodore Baker Andy Wang. Real-Time Scheduling Theory. Analysis techniques to design a system to meet timing constraints Schedulability analysis Workload models Processor models Scheduling algorithms. - PowerPoint PPT Presentation

Text of Sporadic Server Scheduling in Linux Theory vs. Practice Mark Stanovich Theodore Baker Andy Wang

PowerPoint Presentation

Sporadic Server Scheduling in LinuxTheory vs. Practice

Mark StanovichTheodore BakerAndy Wang1Real-Time Scheduling TheoryAnalysis techniques to design a system to meet timing constraintsSchedulability analysisWorkload modelsProcessor modelsScheduling algorithms2Real-Time Scheduling TheoryAnalysis techniques to design a system to meet timing constraintsSchedulability analysisWorkload modelsProcessor modelsScheduling algorithms3

timePeriod = TComputation timeWCET = CDeadline = DTask

jobs (j1, j2, j3, )Release time4Task = {T, C, D}Periodic Task44Periodic Task

sched_setscheduler(SCHED_FIFO)clock_nanosleep()5Periodic TaskAssumptionsWCET is reliableArrivals are periodicNot realistic for most tasks6Polling ServertimetimeJob arrivalsInitialbudgetReplenishment period

7Polling ServerType of aperiodic serverCPU time no worse than an equivalent periodic taskCan be modeled as a periodic taskWCET = Initial BudgetPeriod = Replenishment PeriodBudget consumed as CPU time is usedCPU time forfeited if not usedReplenish budget every period

8Polling ServerGoodBounds CPU timeAnalyzable workloadSimplicityCan be betterFaster response time if budget is not forfeited

9Is maintained?Sporadic ServertimetimeJob arrivalsInitialbudgetReplenishment period

replenishments10Sporadic ServerOriginally proposed by Sprunt et. al.ParametersInitial budgetReplenishment periodBounds CPU interference for other tasksFits into the periodic task workload modelBetter avg. response time than polling server11Sporadic ServerScheduling algorithm for fixed-task-priority systemsCan be used in UNIX priority modelSCHED_SPORADIC is a version of SS defined in POSIX definition

12ImplementationLinux 2.6.38Softirq threading patch ported from earlier RT patchSporadic server implementationUniprocessor13Sporadic Server PerformanceMetricsInterference for lower priority tasksAverage response time14An experiment

Sends UDP packet withcurrent timestampReceives UDP packets

Calculate response time based on arrival at UDP layer

Measure CPU time for 10 second burstAB15Task A floods Task B with ICMP ping messages because they would execute entirely in the context of the device drivers receive thread.Measuring CPU TimeRegher's hourglass techniqueConstantly read time stamp counterDetect preemptions by larger gapsSum execution chunksHourglass thread lower than SS threadMeasures interference from SS thread16Measuring CPU TimeNetwork receive threadSporadic and polling serverBudget = 1 msecPeriod = 10 msecSCHED_FIFOHourglass threadSCHED_FIFOLower priority than network receive thread17CPU Utilization

18Response Time

19InterferenceSS budget limited to CPU demandAdditional overheads lower priority tasks Context switch timeCache eviction and reloadingNot in theoretical workload modelGuarantees of theory require interference to be included in the analysis

20Polling Server21time

= aperiodic job CPU time= aperiodic job arrival

21212121Sporadic Server22time

= aperiodic job CPU time= aperiodic job arrival = replenishment period

22222222Over ProvisioningAll context switch time may not be usede.g., one replenishment per periodAccount for CS time on-lineCharge SS for each preemption23CPU Utilization

24Response Time

25Response Time

26AnalysisLight loadSporadic Server Low response timePolling ServerHigh response timeHeavy loadSporadic ServerHigh response timeDropped packetsPolling ServerLow response timeNo dropped packets2727272727Can we get the best of both?28Sporadic ServerLight loadsPolling ServerHeavy loads28282828Hybrid ServerHow to switchEnsure bounded interferenceSS with 1 replenishment is same as polling serverCoalesce replenishmentsPush replenishments further into the futureSwitching pointServer has work but no budget29Sporadic Servertime

30303030Sporadic Server31time

31313131Response Time

32CPU Utilization

33SwitchingImmediate coalescing may be too extremeCPU time could be used for better response timeGradual approachCoalesce a few replenishments34Sporadic Server35time

35353535Sporadic Server36time

36363636Sporadic Server37time

37373737Response Time

38CPU Utilization

39ConclusionTheoretical analysis provides solid guaranteesImplementation must match abstract modelsAdditional interference terms need to be consideredSS can fit into the theoretical analysis40Deferrable Server

41Deferrable ServerBandwidth PreservingAllow server to retain budgetPeriodically replenish budgetWCET != Budget

42Response Time

4344Replenishment Policyreplenishment period

replenishmentinitial budgettimearrival time(work available for server)4445Bandwidth Preservationreplenishmentinitial budgettimearrival time(work available for server)replenishment period

45Sporadic Server46time

46464646