Roadmap for Section 9.1 Introduction and Vocabulary Performance - - PDF document

▶

Nov 06, 2022 358 likes •540 views

Unit OS9: Real-Time and Embedded Systems 9.1. Introduction and Vocabulary Windows Operating System Internals - by David A. Solomon and Mark E. Russinovich with Andreas Polze Roadmap for Section 9.1 Introduction and Vocabulary Performance

SLIDE 1

1

Windows Operating System Internals - by David A. Solomon and Mark E. Russinovich with Andreas Polze

Unit OS9: Real-Time and Embedded Systems

9.1. Introduction and Vocabulary

Roadmap for Section 9.1

Introduction and Vocabulary Performance Measures General Structure of a Real-Time System Task Assignment and Scheduling Uni- vs. Multi-Processor Scheduling Algorithms Critical Sections and Priority Inversion

SLIDE 2

2

Introduction and Vocabulary

What is a Real-time System? “A real-time system is one in which the correctness of the computations not only depends on the logical correctness of the computation, but also on the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have

ccurred.”

Confusion:

Not a clear definition! What are timing constraints ? (tasks have deadlines)

More confusion

What is the meaning of a “deadline"?

Do all tasks have to be executed before their deadline? (not necessarily) Sometimes “yes”: flight control in an aircraft Sometimes “no”: Multimedia-App.

What is the meaning of “executed“?

How to decide whether a task has been (completely) executed? Relatively simple: bank transaction Impossible: Computation of π

How to deal with tasks that missed their deadlines?

Terminate or run to completion? Aircraft accident vs. Videoconference

SLIDE 3

3

Task Value Functions

Value deadline Value deadline Value deadline

Hard vs. Soft Real-time Systems

Hard real-time systems

Embedded systems: aircraft control, nuclear power plants, chemical reactors, jet engines Missing a deadline has life-threatening results.

Soft real-time systems

Multimedia, airline reservation system Missing a deadline is undesirable and impacts system performance but has not destroy lives or equipment.

SLIDE 4

4

Vocabulary

Example: Car & Driver Well-known example for human control:

Comparable to a real-time computer system in many respects Driver: real-time controller Car: controlled process Road and additional cars: operating environment

Actuators:

Wheels, engine, brakes

Controls:

Steering wheel, brake pedal, switches

Mission Statement

Drive within the allowed speed range from start A to destination B without collisions with other cars or stationary objects. How can driver‘s performance be measured?

Departs from A and reaches destination B Total driving time

But: road conditions have to be taken into account What, if driver leaves the road?

Success: collision could be avoided Failure: control over vehicle was lost

SLIDE 5

5

The Mission – a closer look

Performance is no absolute measure. Performance measures quality of a result in terms of the best possible result under the current environmental conditions. A closer look onto the mission:

Mission critical: steering, brakes Non-critical: radio, lights

Deadlines are not constants (rush hour vs. Sunday drive)

How to measure the drivers physical condition?

Performance Measures

Average values say very little about the performance of a real-time controller. In our scenario:

How to value abrupt acceleration/deceleration maneuvers ? How to measure for unnecessarily increased fuel usage? What about extra slow driving?

SLIDE 6

6

Problems of RT Computing

Reliability, Fault-tolerance

Harsh environments, electromagnetic noise, rapidly changing computation loads

Task Scheduling

Traditional Approach: fairness / round robin scheduling / time slicing RT System: fixed priority scheduling / generalized rate monotonic scheduling / earliest deadline first

Memory Management

Swapping / paging Static pre-allocation (mpin(), vm_wire())

Problems of RT Computing (contd.)

Cache Allocation Policy

Preemption may cause cache invalidation -> missed deadline Does tA = tA1 + tA2 hold?

A B A

A preempted A resumed A completed

tA1 tA2

SLIDE 7

7

Structure of a Real-time System

Controller: RT-Computer/ Uni- vs. Multiprocessor Input data rates: typically < 1 KB/sec Fixed set of processes; software is "pre-loaded“ Scheduler (offline vs. online schedules) Output data rates: typically < 1 command/25 ms

Controlled process Sensors Job list Clock Trigger generator Execution Display Actuators Operator Environment

Data Rates

Sensors/Actuators/Display/Input Panels: low Data conversion/formatting: medium (peripheral area) Control algorithm: high (central cluster) Controlled process often moves through different phases Varying sets of priorities, control tasks, deadlines

Sensor and actuator layer Peripheral area Central cluster

SLIDE 8

8

Task Classes

Periodic, sporadic and aperiodic tasks Critical and non-critical tasks Non-critical real-time (soft real-time tasks): Objective: maximize percentage of jobs successfully executed

Areas of Interest

Architecture

Processor Architecture Network Architecture Architectures for Clock Synchronization Fault-tolerance and Reliability Evaluation

Operating System

Task Assignment and Scheduling Communication Protocols Failure Management and Recovery Clock Synchronization Algorithms

Others

Programming Languages Databases Performance Measures

SLIDE 9

9

Task Assignment and Scheduling

Objective: allocation and scheduling of tasks on processors to ensure that deadlines are met

Problem statement:

Given a set of tasks, task precedence constraints, task characteristics, and deadlines, we are asked to devise a feasible allocation/schedule on a given computer

Task

consumes resources (cpu, memory, input data) produces results

Precedence constraints: Ti needs output from Tj

Task Dependency Graph

Characteristics:

Precedence-relation "<“ Release time Deadline (hard, soft) Relative deadline: absolute deadline - release time

SLIDE 10

10

Periodicity

Periodic: released periodically, every Pi seconds

Period Pi Runs once every period (not exactly every Pi sec)

Sporadic: not periodic, invoked irregularly

Upper bound on invocation rate Aperiodic: sporadic but without bounded invocation rate

Example:

Sensor is read every 10 ms. If value exceeds threshold, signal is send out Sensor task is periodic; period p = 10ms Task that sends the signal is sporadic Maximum invocation rate for this sporadic task?

Feasibility of a Schedule

Task assignment/schedule is feasible if all tasks start after their release times and complete before their deadlines Schedule S: Set of processors x Time

Set of tasks S(i,t) is the task scheduled to be running on processor i at time t Offline scheduling: precomputed schedule Online scheduling: tasks are scheduled at arrival Must be fast Static-priority algorithms: tasks' priorities do not change within a mode (Rate Monotonic Scheduling - RMS) Dynamic-priority algorithms: priority changes with time (Earliest Deadline First - EDF)

SLIDE 11

11

Preemptive vs. non-preemptive Scheduling

Preemptive: tasks can be interrupted by other tasks More flexible Critical task must be allowed to interrupt less critical ones Non-preemptive: task runs until completion or blocking

S1: sub optimal; non-preemptive
S2: T2 misses deadline; non-

preemptive

S3: preemptive; resource optimal
Overhead for preemption;

bookkeeping

Preemption not always possible:

disk write

Uni-processor Scheduling

Traditional rate-monotonic scheduling (RMS)

Periodic, preemptable tasks Deadlines equal task period Set of n tasks is schedulable if total processor utilization is no greater than n(2 1/n-1) Task priorities are static; inversely related to periods Optimal static-priority uniprocessor algorithm Some results for deadline ≠ period

Rate monotonic deferred server (DS)

Similar to RMS Can handle both: periodic and aperiodic tasks

SLIDE 12

12

Uni-processor Scheduling (contd.)

Earliest deadline first (EDF):

Tasks are preemptible Task with earliest deadline has highest priority Optimal uni-processor algorithm If a task set is not schedulable on a single processor by EDF, there is no other processor that can successfully schedule that task set

Precedence and exclusion conditions:

RMS & EDF assume independent preemptible tasks Only processing requirements are taken into account; memory, I/O, other resource requirements negligible

Uni-processor Scheduling (contd.)

Multiple task versions:

System has primary and alternative version of tasks Vary in execution time and quality of output Primary: full-fledged task; top quality output Alternative: bare-bone; lower-quality (acceptable) output; take less much execution time Schedule may pick alternative tasks during overload

IRIS tasks (increased reward with increased service):

Quality of output is monotonically nondecreasing function of execution time Example: iterative algorithms for computation of π

SLIDE 13

13

Multiprocessor Scheduling

Task assignment problem generally is NP-hard Use heuristics

Multiprocessor Scheduling

Utilization balancing algorithm:

Assigns tasks to processors one by one Balanced utilization at end of each step Preemptive tasks

Next-fit algorithm:

Works in conjunction with RMS uni-processor algorithm Divides task set into classes Processors are exclusively assigned to tasks Preemptive tasks

SLIDE 14

14

Multiprocessor Scheduling (contd.)

Bin-packing algorithm:

Assigns tasks to processors so, that utilization does not exceed given threshold Threshold is set so that uni-processor algorithm is able to schedule assigned tasks Preemptive tasks

Myopic offline scheduling algorithm:

Deals with non-preemptive tasks Builds schedule using a search process

Focused addressing and bidding algorithm:

Tasks arrive at individual processors If schedule not feasible: processor may offload some of its workload onto other processors Other processors may voluntarily take over tasks

Multiprocessor Scheduling (contd.)

Buddy strategy:

Three categories: underloaded, fully loaded, and overloaded processors Overloaded processors ask underloaded ones to take over some load

Assignment with precedence constraints:

Takes precedence constraints into account Trial-and-error process: assign communicating processes onto same processor

SLIDE 15

15

Scheduling Problems

Critical Sections:

Source of anomalous behavior: priority inversion Lower-priority tasks can block higher-priority tasks Priority inheritance/priority ceiling protocols: finite upper bound to the period of priority inversion

Mode Changes:

Mission can have multiple phases Different task sets Different priorities/arrival rates How to add/delete tasks of the task list

Fault-Tolerant Scheduling:

Schedule backups in the event of failure

Critical Sections

Binary semaphores Lower priority task may block higher priority task

T3 has lock; blocks T1
T2 interrupts T3

Priority inversion

SLIDE 16

16

Priority Inheritance Protocol

TL blocks TH (by owning a semaphore)... TL inherits temporarily priority of TH Every lower priority task may block higher priority task exactly once per critical section Priority inheritance protocol may create deadlocks

NORMAL TIME_CRITICAL

Time TL locks resource TH starts, request resource TH continues to completion TL is boosted until it frees resource TL runs as scheduled

Priority Ceiling Protocol

Priority ceiling of a semaphore is highest priority of any task that may lock semaphore Priority owner of lock = priority ceiling

P(T2) T2, T3 S4 P(T3) T3 S3 P(T1) T1, T2, T3 S2 P(T1) T1, T2 S1 Priority Ceiling Accessed By Critical Section

Priority ceiling protocol prevents deadlocks

SLIDE 17

17

Requirements for a RT OS

The OS (operating system) must be multithreaded and preemptive The OS must support thread priority A system of priority inheritance must exist The OS must support predictable thread synchronization mechanisms

In addition, the OS behavior must be predictable. This means real-time system developers must have detailed information about the system interrupt levels, system calls, and timing:

The maximum time during which interrupts are masked by the OS and by device drivers must be known. The maximum time that device drivers use to process an interrupt, and specific IRQ information relating to those device drivers, must be known. The interrupt latency (the time from interrupt to task run) must be predictable and compatible with application requirements.