1 / 20

Enforcing Real-Time Behavior

This article explores the concept of real-time systems and the enforcement of operational deadlines. It discusses the difference between hard and soft real-time systems, along with the challenges of managing stricter performance specifications. Additionally, it examines the problems with the O(1) Scheduler and introduces the Completely Fair Scheduler (CFS) as a solution. The article concludes by highlighting the differences between real-time and other processes in Linux.

melbas
Download Presentation

Enforcing Real-Time Behavior

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. Enforcing Real-Time Behavior Chris Gill, James Orr, Son Dinh, and Brian Kocoloski CSE 522S - Advanced Operating Systems Washington University in St. Louis St. Louis, MO 63130

  2. What is meant by real-time? • A system is real-time if it is subject to “operational deadlines” (LSP pp. 190) • E.g., anti-lock brakes in a vehicle • Driver presses brake • Computer regulates pressure • Regulation often entails applying and releasing maximum pressure many times per second • “Real-time” constraints: • Operational, as part of the specification: How fast the system must respond to a “locked wheel” condition • Mechanical: how quickly the system can apply break pressure CSE 522S – Advanced Operating Systems

  3. Hard vs Soft real-time • Hard real-time • Failure to meet operational specification can be catastrophic • Exceeding a deadline even once would be considered a major bug • Soft real-time • Overrunning a deadline is not a critical failure • But, there is a noticeable drop in performance/user experience/etc. when deadlines are missed • Neither soft nor real time systems should be considered “fast” • In fact, there is added overhead in comparison to non-real time systems due to added challenge of managing stricter performance specifications • Hard vs. soft is about importance of meeting deadlines – not about duration of intervals between deadlines/events CSE 522S – Advanced Operating Systems

  4. First: non-real time • Linux characterizes non real-time tasks as either compute bound or I/O bound • Compute bound • Makes heavy use of the processor, non-interactive, does not care about latency • Considered low priority in Linux • I/O bound • Makes only sporadic use of the processor, reads/writes storage/network data, or waits for user input; cares about latency • Considered high priority in Linux • Example (LKD pp 45) • App 1: text editor (I/O bound) • App 2: video encoder (compute bound) CSE 522S – Advanced Operating Systems

  5. Problems with O(1) Scheduler O(1) philosophy: fixed timeslices for different priority levels Assume: nice 0 = 100 mstimeslice nice 1 = 95 mstimeslice … nice 19 = 5 ms (lowest priority) What would timeslice allocations be for: • One video encoder (nice 19) and one text editor (nice 0)? • Two video encoder tasks? • Two text editor tasks? CSE 522S – Advanced Operating Systems

  6. Problems with O(1) Scheduler • Inverted switching rates • High priority (low nice value) tasks are generally interactive, I/O intensive • Low priority (high nice value) tasks are generally compute bound • Further consider two low priority processes – they will switch every 5 ms • Two high priority processes – they will switch every 100 ms • Additional problems? • Variance across nice intervals • Nice values of 0,1 get timeslices of 100,95 ms (5% decrease) • Nice values of 18,19 get timesliices of 10,5 ms (50% decrease) • Need absolute timeslices, limited by HW capability CSE 522S – Advanced Operating Systems

  7. Completely Fair Scheduler (CFS) Goal: All tasks receive a weighted proportion of processor time. • On a system with N tasks, each task should be promised 1/N processor time • i.e. “completely fair” • Allows interactive tasks to run at high priority while sharing CPU equally between CPU bound tasks. • Fundamental idea: • Abandons notion of fixed timeslice (and varying fairness), for fixed fairness (and varying timeslice) CSE 522S – Advanced Operating Systems

  8. Same example, but with CFS • Consider our video encoder and text editor once again • Now, rather than fixed timeslices, we need a target latency – a single absolute value that reflects how “responsive” the system should feel • e.g. 20 ms • Assume nice values of 0 and 20 • This works out to about 95% of the processor for nice 0 and 5% of the processor for nice 20 • So, timeslices would be 19 ms and 1 ms • What about two text editors? Two video encoders? CSE 522S – Advanced Operating Systems

  9. Virtual Runtime Virtual runtime: the actual running time of a process weighted by its priority, stored as nanoseconds value • If all tasks have nice priority 0, their virtual runtime is equal to their actual runtime • If some task has nonzero priority, then: where weights are determined by nice priority. • Updated in update_curr() infair.c CSE 522S – Advanced Operating Systems

  10. Difference between RT and OTHER processes in Linux • Linux default scheduling algorithm: CFS • Length of timeslice is a function of how much work the system is doing and the target latency • e.g., if there are 100 processes vs 10 processes, timeslices are roughly going to change by a factor of 10 • What are the implications of this for a real-time system? CSE 522S – Advanced Operating Systems

  11. Difference between RT and OTHER processes in Linux • Linux default scheduling algorithm: CFS • Length of timeslice is a function of how much work the system is doing and the target latency • e.g., if there are 100 processes vs 10 processes, timeslices are roughly going to change by a factor of 10 • What are the implications of this for a real-time system? • This variation is a horrible fit for real-time workloads with fixed deadlines • However, CFS is better at achieving fairness and improving system throughout • This is a good example of why real-time systems are generally not “faster” – they explicitly tradeoff throughout to allow meeting strict runtime specifications CSE 522S – Advanced Operating Systems

  12. Determinism • Real-time processes are big on determinism • In real-time computing, an action is deterministic if, given the same input, it always produces the same result in the same amount of time • “Modern computers are the very definition of something that is not deterministic” • Why? CSE 522S – Advanced Operating Systems

  13. Determinism • Real-time processes are big on determinism. • In real-time computing, an action is deterministic if, given the same input, it always produces the same result in the same amount of time • “Modern computers are the very definition of something that is not deterministic” • multiple levels of caches (which incur hits or misses without predictability) • multiple processors, paging, swapping, and multitasking wreak havoc on any estimate of how long a given action will take CSE 522S – Advanced Operating Systems

  14. Uniprocessor Real-Time Systems • Each task τi is modeled as cyclic process, with period Ti, deadline Di, and computation time Ci • Ex: Task τ1 T1=D1=5, C1=4 • Goal: meet all tasks’ deadlines τ1 τ1 τ1 Time 0 5 10 15 C. Liu, and J. Layland, “Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment,” Journal of the ACM 20(1), January 1973. CSE 522S – Advanced Operating Systems

  15. Real-Time Terminology • Release time is when a job of a task is ready • Start time is when a job is first scheduled • Response time is completion minus release • Sometimes also called “response latency” • Execution time is sum of scheduled intervals • Jitter is the variation in any one of those • Higher priority job may preempt running one Τ1,1 Τ2,1 Τ1,1 Time released resumed preempted completed CSE 522S – Advanced Operating Systems

  16. Scheduling Classes Linux schedulers are implemented as different scheduling classes Normal: • SCHED_IDLE: lowest priority scheduler • SCHED_BATCH: low priority, non-interactive CFS tasks • SCHED_NORMAL: regular, interactive CFS tasks Real-time: • SCHED_RR: round-robin • SCHED_FIFO: first-in, first-out • SCHED_DEADLINE: earliest deadline first (rt-preempt) CSE 522S – Advanced Operating Systems

  17. SCHED_FIFO First-in, First-out scheduling • The first enqueued task of highest priority executes to completion • A task will only relinquish a processor when it completes, yields, or blocks Task 1 Task 2 Task 3 Time CSE 522S – Advanced Operating Systems

  18. SCHED_RR Round-robin scheduling Among tasks of equal priority: • Rotate through all tasks • Each task gets a fixed time slice Cannot run if higher priority tasks are runnable Task 1 Task 2 Task 3 Task 1 Task 2 Task 3 Task 1 Task 2 Task 3 Time CSE 522S – Advanced Operating Systems

  19. SCHED_DEADLINE Earliest Deadline First (EDF)scheduling • Whichever task has next deadline gets to run • Theory exists to analyze such systems • Linux implements bandwidth reservation to prevent deadline abuse Deadline: 5Exec time: 4 Deadline: 12Exec time: 3 Deadline: 8Exec time: 2 Task 1 Task 2 Task 3 Task 1 Task 3 Task 2 Time 0 5 8 12 CSE 522S – Advanced Operating Systems

  20. RT System Calls e.g., set the scheduler class to SCHED_RR and the RT priority to 1 e.g., get the timeslice for the current RT task CSE 522S – Advanced Operating Systems

More Related