1 / 83

MC 2 : Mixed Criticality on Multicore

MC 2 : Mixed Criticality on Multicore. Jim Anderson University of North Carolina at Chapel Hill. Driving Problem Joint Work with Northrop Grumman Corp. Next-generation UAVs. Pilot functions performed using “AI-type” software.

cate
Download Presentation

MC 2 : Mixed Criticality on Multicore

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MC2: Mixed Criticality on Multicore Jim Anderson University of North Carolina at Chapel Hill

  2. Driving ProblemJoint Work with Northrop Grumman Corp. • Next-generation UAVs. • Pilot functions performed using “AI-type” software. • Causes certification difficulties. • Workload is dynamic and computationally intensive. • Suggests the use of multicore. • Our focus:What should the OS look like? • Particular emphasis: Real-time constraints. • Implies that we care about real-time OSs (RTOSs). Image source: http://www.as.northropgrumman.com/products/nucasx47b/assets/lgm_UCAS_3_0911.jpg

  3. Multicore in Avionics: The Good Core 1 Core M … • Enables computationally- intensive workloads to be supported. • Enables SWAP reductions. • SWAP = size, weight, and power. • Multicore is now the standard platform. L1 L1 L2

  4. Multicore in Avionics: The Bad & Ugly Core 1 Core M … • Interactions across cores through shared hardware (caches, buses, etc.) are difficult to predict. • Results in very conservative execution-time estimates (and thus wasted processing resources). One Approach:Accept this fact. Use resulting slack for less critical computing. L1 L1 L2 “Multicore processors arebig slack generators.”

  5. What is “Less Critical”? more conservative design less conservative design • Consider, for example, the criticality levels of DO-178B: • Level A: Catastrophic. • Failure may cause a crash. • Level B:Hazardous. • Failure has a large negative impact on safety or performance… • Level C:Major. • Failure is significant, but… • Level D: Minor. • Failure is noticeable, but… • Level E:No Effect. • Failure has no impact.

  6. Starting Assumptions • Modest core count (e.g., 2-8). • Quad-core in avionics would be a tremendous innovation.

  7. Starting Assumptions • Modest core count (e.g., 2-8). • Modest number of criticality levels (e.g., 2-5). • 2 may be too constraining •  isn’t practically interesting. • These levels may not necessarily match DO-178B. • Perhaps 3 levels? • Safety Critical: Operations required for stable flight. • Mission Critical: Responses typically performed by pilots. • Background Work: E.g., planning operations.

  8. Starting Assumptions • Modest core count (e.g., 2-8). • Modest number of criticality levels (e.g., 2-5). • Statically prioritize criticality levels. • Schemes that dynamically mix levels may be problematic in practice. • Note: This is done in much theoretical work on mixed criticality scheduling. • For example, support for resource sharing and implementation overheads may be concerns. • Also, practitioners tend to favor simple resource sharing schemes.

  9. Starting Assumptions • Modest core count (e.g., 2-8). • Modest number of criticality levels (e.g., 2-5). • Statically prioritize criticality levels.

  10. Outline • Background. • Real-time scheduling basics. • Real-time multiprocessor scheduling. • Mixed-criticality scheduling. • MC2 design. • Scheduling and schedulability guarantees. • MC2 implementation. • OS concerns. • Future research directions.

  11. Basic Task Model Assumed • Set  = {T = (T.e,T.p)} ofperiodic tasks. • T.e = T’s worst-case per-job execution cost. • T.p = T’s period & relative deadline. • T.u = T.e/T.p = T’s utilization. 5 2 T = (2,5) One Core Here U = (9,15) job release 0 5 10 15 20 25 30 job deadline processor 1

  12. Basic Task Model Assumed • Set  = {T = (T.e,T.p)} ofperiodic tasks. • T.e = T’s worst-case per-job execution cost. • T.p = T’s period & relative deadline. • T.u = T.e/T.p = T’s utilization. 5 2 T = (2,5) One Core Here U = (9,15) job release 0 5 10 15 20 25 30 job deadline processor 1

  13. Basic Task Model Assumed • Set  = {T = (T.e,T.p)} ofperiodic tasks. • T.e = T’s worst-case per-job execution cost. • T.p = T’s period & relative deadline. • T.u = T.e/T.p = T’s utilization. 5 2 T = (2,5) One Core Here U = (9,15) job release 0 5 10 15 20 25 30 job deadline processor 1

  14. Basic Task Model Assumed • Set  = {T = (T.e,T.p)} ofperiodic tasks. • T.e = T’s worst-case per-job execution cost. • T.p = T’s period & relative deadline. • T.u = T.e/T.p = T’s utilization. 5 2 T = (2,5) 2/5 One Core Here U = (9,15) job release 0 5 10 15 20 25 30 job deadline processor 1

  15. Basic Task Model Assumed • Set  = {T = (T.e,T.p)} ofperiodic tasks. • T.e = T’s worst-case per-job execution cost. • T.p = T’s period & relative deadline. • T.u = T.e/T.p = T’s utilization. This is an example of an earliest-deadline-first (EDF) schedule. 5 2 T = (2,5) One Core Here U = (9,15) job release 0 5 10 15 20 25 30 job deadline processor 1

  16. Multiprocessor Real-Time Scheduling Two Approaches: Partitioning Global Scheduling Today, we’ll mainly consider partitioned earliest-deadline-first (P-EDF) and global earliest deadline-first (G-EDF) scheduling… • Steps: • Assign tasks to processors (bin packing). • Schedule tasks on each processor using uniprocessor algorithms. • Important Differences: • One task queue. • Tasks may migrate among the processors.

  17. Hard vs. Soft Real-Time • HRT: No deadline is missed. • We assume all HRT tasks commence execution at time 0 and periods are harmonic (smaller periods divide larger ones). • SRT: Deadline tardiness is bounded. • We allow SRT tasks to be non-harmonic and also sporadic (T’s job releases are at leastT.p time units apart). • A wide variety of global scheduling algorithms are capable of ensuring bounded tardiness with no utilization loss.

  18. Scheduling vs. SchedulabilityWhat’s “Utilization Loss”? Utilization loss occurs when test requires utilizations to be restricted to get a “yes” answer. no timing requirement will be violated if  is scheduled with EDF a timing requirement will (or may) be violated … • W.r.t. scheduling, we actually care about two kinds of algorithms: • Scheduling algorithm(of course). • Example: Earliest-deadline-first (EDF): Jobs with earlier deadlines have higher priority. • Schedulability test. yes Test for EDF  no

  19. P-EDFUtil. Loss for Both HRT and SRT Example: Partitioning three tasks with parameters (2,3) on two processors will overload one processor. In terms of bin-packing… • Under partitioning & most global algorithms, overall utilization must be capped to avoid deadline misses. • Due to connections to bin-packing. • Exception: Global “Pfair” algorithms do not require caps. • Such algorithms schedule jobs one quantum at a time. • May therefore preempt and migrate jobs frequently. • Perhaps less of a concern on a multicore platform. • Under most global algorithms, if utilization is not capped, deadline tardinessis bounded. • Sufficient for soft real-time systems. Task 1 1 Task 2 Task 3 0 Processor 2 Processor 1

  20. G-EDFHRT: Loss, SRT: No Loss deadline miss Note: “Bin-packing” here. Previous example scheduled under G-EDF… • Under partitioning & most global algorithms, overall utilization must be capped to avoid deadline misses. • Due to connections to bin-packing. • Exception: Global “Pfair” algorithms do not require caps. • Such algorithms schedule jobs one quantum at a time. • May therefore preempt and migrate jobs frequently. • Perhaps less of a concern on a multicore platform. • Under most global algorithms, if utilization is not capped, deadline tardinessis bounded. • Sufficient for soft real-time systems. processor 1 processor 2 T1 = (2,3) T2 = (2,3) T3 = (2,3) 0 5 10 15 20 25 30

  21. Mixed-Criticality SchedulingProposed by Vestal [2007] • In reality, task execution times may vary widely. • Vestal noted that different design and analysis methods are used at different criticality levels. • Greater pessimism at higher levels. • He suggested reflecting such differences in schedulability analysis. Average Proven Worst Case Measured Worst Case

  22. Mixed-Criticality SchedulingProposed by Vestal [2007] • Mixed-Criticality Task Model: Each task has an execution cost specified at each criticality level. • Costs at higher levels are (typically) larger. • Example: T.eA = 20, T.eB = 12, T.eC = 5, … • Rationale: Will use more pessimistic analysis at high levels, more optimistic at low levels.

  23. Mixed-Criticality SchedulingProposed by Vestal [2007] Some “weirdness” here: Not just one system anymore, but several: the level-A system, level-B,… • Mixed-Criticality Task Model: Each task has an execution cost specified at each criticality level. • Costs at higher levels are (typically) larger. • The task system is correctat level Xiffall level-X tasks meet their timing requirements assuming all tasks have level-X execution costs.

  24. Outline • Background. • Real-time scheduling basics. • Real-time multiprocessor scheduling. • Mixed-criticality scheduling. • MC2 design. • Scheduling and schedulability guarantees. • MC2 implementation. • OS concerns. • Future research directions.

  25. Recall These Assumptions… • Modest core count (e.g., 2-8). • Modest number of criticality levels (e.g., 2-5). • Statically prioritize criticality levels.

  26. MC2: Mixed-Criticality on MulticoreOur Proposed Mixed-Criticality Architecture (Joint with NGC) • We assume four criticality levels, A-D. • Originally, we assumed five, like in DO-178B. • We statically prioritize higher levels over lower ones. • We assume: • Levels A & B require HRT guarantees. • Level C requires SRT guarantees. • Level D is non-RT.

  27. Level-A Scheduling“Absolute, Under All Circumstances, HRT” • Partitioned scheduling is used, with a cyclic executive on each core. • Cyclic executive: offline-computed dispatchingtable. • Now the de facto standard in avionics. • Preferred by certification authorities. • But somewhat painful from a software-development perspective. • Require: • Total per-core level-A utilization  1 (assuming level-A execution costs). • Sufficient to ensure that tables can be constructed (no level-A deadline is missed).

  28. So Far… Core 1 Core 2 Core 3 Core 4 higher (static) priority CE CE CE CE Level A Level B Level C lower (static) priority Level D

  29. Level-B Scheduling“HRT Unless Something Really Unexpected Happens” • Use P-EDF scheduling. • Prior work @ UNC has shown that P-EDF excels at HRT scheduling. • Harmonic periods  can instead use partitioned rate-monotonic (P-RM). • Eases the software-development pain of CEs. • Require: • Total per-core level-A+B utilization  1 (assuming level-B execution costs). (*) • Each level-B period is a multiple of the level-A hyperperiod(= LCM of level-A periods). (**) • More on this later. • (*) and (**)  if no level-A+B task ever exceeds its level-B execution cost, then no level-B task will miss a deadline.

  30. So Far… Core 1 Core 2 Core 3 Core 4 higher (static) priority CE CE CE CE Level A Level B EDF/RM EDF/RM EDF/RM EDF/RM Level C lower (static) priority Level D

  31. Level-C Scheduling“SRT” • Use G-EDF scheduling. • Prior work @ UNC has shown that G-EDF excels at SRT scheduling. • Require: • Total level-A+B+C utilization  M= number of cores (assuming level-C execution costs). • Theorem[Prior work @ UNC]: G-EDF ensures bounded deadline tardiness, even on restricted-capacity processors, if no over-utilization and certain task util. restrictions hold. • These restrictions aren’t very limiting if level-A+B utilization (assuming level-C execution costs) is not large. • Bottom Line: If no level-A+B+C task ever exceeds its level-C execution cost, can ensure bounded tardiness at level C.

  32. So Far… Core 1 Core 2 Core 3 Core 4 higher (static) priority CE CE CE CE Level A Level B EDF/RM EDF/RM EDF/RM EDF/RM Level C G-EDF lower (static) priority Level D

  33. Level-D Scheduling“Best Effort” • Ready level-D tasks run whenever there is no pending level-A+B+C work on some processor. • Seems suitable for potentially long-running jobs that don’t require RT guarantees.

  34. Full Architecture Core 1 Core 2 Core 3 Core 4 higher (static) priority CE CE CE CE Level A Level B EDF/RM EDF/RM EDF/RM EDF/RM Level C G-EDF lower (static) priority Level D Best Effort

  35. Remaining Issues • Why the level-B period restriction? • Budgeting • Slack shifting.

  36. Example Task System(All Tasks on the same Processor)

  37. Example Task System(All Tasks on the same Processor) This violates our level-B period assumption.

  38. Example Task System(All Tasks on the same Processor) Each level-A task has a different execution cost (and hence utilization) per level. Execution costs (and hence utilizations) are larger at higher levels.

  39. “Level-ASystem” = job release = job deadline T1 = (5,10) T2= (10,20) 0 5 10 15 20 25 30 35 40 Higher levels have statically higher priority. Thus, level-A tasks are oblivious of other tasks.

  40. “Level-BSystem” = job release = job deadline T1 = (3,10) T2= (6,20) T3 = (2,10) T4= (8,40) 0 5 10 15 20 25 30 35 40 T3misses some deadlines. This is because our period constraint for level B is violated. We can satisfy this constraint by “slicing” each job of T2 into two “subjobs”…

  41. “Level-BSystem” = job release = job deadline T1 = (3,10) T2= (3,10) T3 = (2,10) T4= (8,40) 0 5 10 15 20 25 30 35 40 All deadlines are now met.

  42. Budgeting • MC2 optionally supports budget enforcement. • The OS treats a level-X task’s level-X execution time as a budget that cannot be exceeded. Job 1 Job 2 Provisioned Job 3 Without BE With BE 0 5 10 15 20 25 30 35 40

  43. Budgeting • MC2 optionally supports budget enforcement. • The OS treats a level-X task’s level-X execution time as a budget that cannot be exceeded. • Pro: Makes “job slicing” easier. • Con: Can make the system less resilient in dealing with breeches of execution-time assumptions. • More on this later.

  44. Slack Shifting • Provisioned execution times at higher criticality levels may be very pessimistic. • At level A, WCETs (worst-case execution times) may be much higher than actual execution times. • Thus, higher levels produce “slack” that can be consumed by lower levels. • Could lessen tardiness at level C… • … or increase throughput at level D.

  45. Slack Shifting (Cont’d) • Slack Shifting Rule: • When a level-X job under-runs its level-X execution time, it becomes a “ghost job.” • When a ghost job is scheduled, its processor time is donated to lower levels. • Such donations do not invalidate correctness properties.

  46. A (Very) Simple Example execution time (at level B) … Level B … Donated Level C 0 5 10 15 20 25 30

  47. Without Slack Shifting Remember, could be huge. execution time (at level B) … Level B … finishes later Level C 0 5 10 15 20 25 30

  48. Spare Capacity Reclamation Summary • MC2 does this in two ways: • At design time:This occurs when we validate level-X RT guarantees. • This is done assuming execution costs “appropriate” for level X. • At run time:MC2 uses slack shifting to re-allocate available slack. • This exploits the fact that actual execution costs (at whatever level) may be less than provisioned costs.

  49. Outline • Background. • Real-time scheduling basics. • Real-time multiprocessor scheduling. • Mixed-criticality scheduling. • MC2 design. • Scheduling and schedulability guarantees. • MC2 implementation. • OS concerns. • Future research directions.

  50. LITMUSRT Implementation of MC2 • Real-time Linux extension originally developed at UNC. • (Multiprocessor) scheduling and synchronization algorithms implemented as “plug-in” components. • Developed as a kernel patch (currently based on Linux 3.10.5). • Code is available at http://www.litmus-rt.org/. Linux Testbed for Multiprocessor Scheduling in Real-Time systems

More Related