Introduction to Embedded Systems Research: Scheduling ...ziyang.eecs.umich.edu/~dickrp/iesr/lectures/l6.pdfIntroduction to Embedded Systems Research: Scheduling, embedded OSs, and

Introduction to Embedded Systems Research:Scheduling, embedded OSs, and CPS

Robert Dick

[email protected] of Electrical Engineering and Computer Science

University of Michigan

Fovea

Lens

Cornea

Variable Resolution

and Position Sampling

Change-Adaptive

Signalling

Spatial State

Cache

(Occipital

Place Area)

Analasys, e.g.,

Classification

Adequate

decision confidence?

Sampling Guidance

Y

N

Long-Term Memory

Decision /

Result

(b) Iterative, multi-round human vision system.

Image Signal

Processor

Application Processor

(CPU and/or GPU)

CloudDecision /

Result

(a) Conventional machine vision pipeline.

Image Sensor: typically

homogeneous RGGB or RCCC.

Demosaicing, binning,

denoising, gamma

correction, and compression.

Hardware Feature

Extraction Accelerator

or

Feature extraction on

raw captured data.

Runs CNN, LSTM or

other analysis algorithm.

May drop computation on less

important data, but already payed

Image Signal Processor transfer cost.

May render decision or (at high

energy cost) do feature extraction

and defer decision to cloud.

Minimalistic

Image Pre-Processor

Application Processor

(CPU and/or GPU)

CloudDecision /

Result

Image Sensor: capture only the

most important

data for decision accuracy.

Efficient gamma

correction

and binning.

Decide based on features.

Very high energy cost for

wireless data transfer.

Scene Cache

Capture ControllerHardware Feature

Extraction Accelerator

or

Adequate

decision confidence?

or

Y

N

Captures most relevant

and rapidly changing data.

Learns important sample locations

from prior rounds.

Maintains state built from

prior still-relevant samples.

Determine and

transmit

relevant data.

Decide based on features.

Very high energy cost for

wireless data transfer.

Issue commands to

capture important data.

(c) Goal: multi-round, energy-efficient, low-latency

continuous learning machine vision.

Feature extraction on sparse captured

data with similar distribution to processed data.

Continuously learn features and important

data based on prior captures.

1.1040

2.1041

385

2.1039

704

1.1039

36

2.1040

1734

0.1039

1

3.1040

4

4.1039

642

3.1039

4.1040

409

3.1041

396665

5.1042

108612774

5.1040

337

4.1041

10644

6.1044

117

6.1039

609

6.1045

164

6.1040

841434 723938

6.1042

209

5.1041

4 12 164

5.1045

529417

5.1044

140105 88

5.1039

154 10551 90677

7.1039

1248

7.1047

2106

7.1040

29773362 241966 22903106

6.1041

3119 1936 40

6.1047

4128 253

8.1050

4

8.1042

9.1050

24784

8.1039

89632

8.1044

2840

8.1040

1088

9.1039

10.1040

4

11.1039

957

10.1050

144

11.1040

156

10.1041

32 16

10.1047

87780

10.1045

2152

10.1039

1165

12.1040

145

13.1052

2404

12.1042

24

12.1045

33008

12.1044

8217

12.1041

8

12.1039

135427

14.1049

113

14.1040

229

13.1050

132

13.1042

74433

13.1041

17187

13.1040

2715

13.1039

170059 90

15.1040

16

15.1050

242 1225

14.1050

237

14.1042

6200

14.1041

4

14.1044

720

14.1052

20

14.1039

84 36939

16.1040

88

15.1049

6

15.1039

56

17.1054

2919

16.1050

129

16.1041

36

16.1047

49154

16.1045

2632

16.1049

27

16.1052

16

16.1039

222734

18.1048

133

18.1039

3439

18.1040

241

17.1050

16

18.1049

36 339224

17.1042

172832

17.1041

49620 448

17.1040

1376493 2883

17.1045

72

17.1044

1073

17.1049

55441826

17.1048

124 3648290

17.1052

3547

17.1039

2484110477445

17.1047

24

19.1040

72

19.1039

6 88 60631617

18.1041

28 76

18.1047

3305

18.1054

13744

20.1040

109

20.1039

269

19.1052

8

19.1047

11712

19.1049

10

19.1054

7520

21.1039

82

20.1049

5

20.1047

4896

20.1054

864

22.1040

4

22.1050

23.1040

4

22.1039

144

24.1058

3389

23.1050

76

24.1040

4

23.1042

17528

23.1041

4

23.1054

24

23.1044

6234

23.1058

261

23.1049

4

23.1052

2944

23.1039

3069658

25.1040

80

24.1050

4

24.1039

58

25.1039

26.1040

4

27.1039

489

26.1050

4

27.1040

4

26.1047

3808

26.1045

2248

26.1058

113 80

26.1049

11

26.1039

66

26.1054

840

28.1055

84266 1542

27.1042

1229

27.1041

29619

27.1058

12

27.1049

3984

27.1048

35337

29.1040

262

29.1056

164

29.1039

742

28.1050

4 2464

28.1042

2137912

29.1055

1128

28.1041

4 2633 4

28.1040

2716132 691

28.1058

24 84 32

28.1049

36176 3

28.1048

1192 48

28.1039

365 110957 24475

29.105029.104229.104129.104729.104529.105829.104929.105229.1054

2

3

4

5

6

7

8

0 1 2 3 4 5 6 7 8

Pow

er

(mW

)

Time (s)

35 40 45 50 55 60 65 70 75 80 85 90

-8 -6 -4 -2 0 2 4 6 8

-8

-6

-4

-2

0

2

4

6

8

35 40 45 50 55 60 65 70 75 80 85 90

Temperature (°C)

Position (mm)

Temperature (°C)

Realtime systemsRate Monotonic Scheduling

Real-time and embedded operating systemsCyber-physical systems overview

Deadlines and announcements

TaxonomyDefinitionsCentral areas of real-time study

Outline

1. Realtime systems

2. Rate Monotonic Scheduling

3. Real-time and embedded operating systems

4. Cyber-physical systems overview

5. Deadlines and announcements

2 R. Dick EECS 507





Section outline

1. Realtime systemsTaxonomyDefinitionsCentral areas of real-time study

3 R. Dick EECS 507





Taxonomy of real-time systems

DynamicStatic

4 R. Dick EECS 507






Soft Hard

5 R. Dick EECS 507






Single rate Multi−rate

Periodic Aperiodic

Bounded

arrival intervalUnbounded

arrival interval

6 R. Dick EECS 507






DynamicStatic Soft Hard Single rate Multi−rate

Periodic Aperiodic

Bounded


arrival interval

7 R. Dick EECS 507






DynamicStatic Soft Hard Single rate Multi−rate

Periodic Aperiodic

Bounded


arrival interval

8 R. Dick EECS 507





Static

Task arrival times can be predicted.

Static (compile-time) analysis possible.

Allows good resource usage (low processor idle time proportions).

Sometimes designers shoehorn dynamic problems into static formulationsallowing a good solution to the wrong problem.

9 R. Dick EECS 507





Dynamic

Task arrival times unpredictable.

Static (compile-time) analysis possible only for simple cases.

Even then, the portion of required processor utilization efficiency goes to0.693.

In many real systems, this is very difficult to apply in reality (more on thislater).

Use the right tools but don’t over-simplify, e.g.,

We assume, without loss of generality, that all tasks are independent.

10 R. Dick EECS 507





Soft real-time

More slack in implementation.

Timing may be suboptimal without being incorrect.

Problem formulation can be much more complicated than hard real-time.

Two common (and one uncommon) methods of dealing with non-trivial softreal-time system requirements.

Set somewhat loose hard timing constraints.

Informal design and testing.

Formulate as optimization problem.

11 R. Dick EECS 507





Hard real-time

Difficult problem. Some timing constraints inflexible.

Simplifies problem formulation.

12 R. Dick EECS 507





Periodic

Each task (or group of tasks) executes repeatedly with a particular period.

Allows some nice static analysis techniques to be used.

Matches characteristics of many real problems. . .

. . . and has little or no relationship with many others that designers try topretend are periodic.

13 R. Dick EECS 507





Periodic → single-rate

One period in the system.

Simple.

Inflexible.

This is how a lot of wireless sensor networks are implemented.

14 R. Dick EECS 507





Periodic → multirate

Multiple periods.

Can use notion of circular time to simplify static (compile-time) scheduleanalysis E. L. Lawler and D. E. Wood, “Branch-and-bound methods: Asurvey,” Operations Research, pp. 699–719, July 1966.

Co-prime periods leads to analysis problems.

15 R. Dick EECS 507





Periodic → other

It is possible to have tasks with deadlines less than, equal to, or greater thantheir periods.

Results in multi-phase, circular-time schedules with multiple concurrent taskinstances.

If you ever need to deal with one of these, see me (take my code). This classof scheduler is nasty to code.

16 R. Dick EECS 507





Aperiodic

Also called sporadic, asynchronous, or reactive.

Implies dynamic.

Bounded arrival time interval permits resource reservation.

Unbounded arrival time interval impossible to deal with for anyresource-constrained system.

17 R. Dick EECS 507





Section outline


18 R. Dick EECS 507





Definitions

Task.

Processor.

Graph representations.

Deadline violation.

Cost functions.

19 R. Dick EECS 507





Task

Some operation that needs to be carried out.

Atomic completion: A task is all done or it isn’t.

Non-atomic execution: A task may be interrupted and resumed.

20 R. Dick EECS 507





Processor

Processors execute tasks.

Distributed systems.

Contain multiple processors.

Inter-processor communication has impact on system performance.

Communication is challenging to analyze.

One processor type: Homogeneous system.

Multiple processor types: Heterogeneous system.

21 R. Dick EECS 507





Task/processor relationship

Matrix

FIR

Tooth

Road

WC exec time (s)

310E−3

...

...

...

...

7.7E−6

330E−9

4.1E−6

IBM PowerPC 405GP 266 MHz

IDT79RC32364 100 MHz

Imsys Cjip 40 MHz

Relationship between tasks, processors, and costs.

Examples: power consumption or worst-case execution time.

22 R. Dick EECS 507





Cost functions

Mapping of real-time system design problem solution instance to cost value.

I.e., allows price, or hard deadline violation, of a particular multi-processorimplementation to be determined.

23 R. Dick EECS 507





Back to real-time problem taxonomy: jagged edges

Some things can dramatically complicate real-time scheduling.

Data dependencies.

Unpredictability.

Distributed systems.

Heterogeneous processors.

Preemption.

24 R. Dick EECS 507





Section outline


25 R. Dick EECS 507





Central areas of real-time study

Allocation, assignment and scheduling.

Operating systems and scheduling.

Distributed systems and scheduling.

Scheduling is at the core of real-time systems study.

26 R. Dick EECS 507





Operating systems and scheduling

How does one best design operating systems to

Support sufficient detail in workload specification to allow good control, e.g.,over scheduling, without increasing design error rate.

Design operating system schedulers to support real-time constraints?

Support predictable costs for task and OS service execution.

27 R. Dick EECS 507





Distributed systems and scheduling

How does one best dynamically control

The assignment of tasks to processing nodes...

... and their schedules.

for systems in which computation nodes may be separated by vast distancessuch that

Task deadline violations are bounded (when possible)...

... and minimized when no bounds are possible.

28 R. Dick EECS 507





The value of formality: optimization and costs

The design of a real-time system is fundamentally a cost optimizationproblem.

Minimize costs under constraints while meeting functionality requirements.

Functionality requirements are actually just constraints.

Why view problem in this manner?

Without having a concrete definition of the problem.

How is one to know if an answer is correct?

More subtly, how is one to know if an answer is optimal?

29 R. Dick EECS 507





Optimization

Thinking of a design problem in terms of optimization gives design teammembers objective criterion by which to evaluate the impact of a designchange on quality.

Know whether your design changes are taking you in a good direction

30 R. Dick EECS 507




Outline

1. Realtime systems





31 R. Dick EECS 507

Primary publication

C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogrammingin a hard-real-time environment,” J. of the ACM, vol. 20, no. 1, pp. 46–61,Jan. 1973.




Rate mononotic scheduling (RMS)

Single processor.

Independent tasks.

Differing arrival periods.

Schedule in order of increasing periods.

No fixed-priority schedule will do better than RMS.

Guaranteed valid for loading ≤ ln 2 = 0.69.

For loading > ln 2 and < 1, correctness unknown.

Usually works up to a loading of 0.88.

33 R. Dick EECS 507

Rate monotonic scheduling

1973, Liu and Layland derived optimal scheduling algorithm(s) for thisproblem.

C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogrammingin a hard-real-time environment,” J. of the ACM, vol. 20, no. 1, pp. 46–61,Jan. 1973.

Schedule the job with the smallest period (period = deadline) first.

Analyzed worst-case behavior on any task set of size n.

Found utilization bound: U(n) = n · (21/n − 1).

0.828 at n = 2.

As n→∞, U(n)→ log 2 = 0.693.

Result: For any problem instance, if a valid schedule is possible, theprocessor need never spend more than 31% of its time idle.




Optimality and utilization for limited case

Simply periodic: All task periods are integer multiples of all lesser taskperiods.

In this case, RMS/DMS optimal with utilization 1.

However, this case rare in practice.

Remains feasible, with decreased utilization bound, for in-phase tasks witharbitrary periods.

35 R. Dick EECS 507




Rate monotonic scheduling

Constrained problem definition.

Over-allocation often results.

However, in practice utilization of 85%–90% common.

Lose guarantee.

If phases known, can prove by generating instance.

36 R. Dick EECS 507




Critical instants

Definition

A job’s critical instant a time at which all possible concurrent higher-priorityjobs are also simultaneously released.

Useful because it implies latest finish time

37 R. Dick EECS 507




Definitions

Period: T .

Execution time: C .

Process: i .

Utilization: U =∑m

i=1Ci

Ti.

Assume Task 1 is higher priority than Task 2, and thus T1 < T2.

38 R. Dick EECS 507




Critical instants

C1

T1

C1

C2

C1

T1 T1

Case 1 Case 2

T2

39 R. Dick EECS 507




Case 1 I

All instances of higher-priority tasks released before end of lower-priority taskperiod complete before end of lower-priority task period.

C1 ≤ T2 − T1

⌊T2

T1

⌋.

I.e., the execution time of Task 1 is less than or equal to the period ofTask 2 minus the total time spent within the periods of instances of Task 1finishing within Task 2’s period.

Now, let’s determine the maximum execution time of Task 2 as a function ofall other variables.

Number of T1 released =⌈T2

T1

⌉so C2,max = T2 − C1

⌈T2

T1

⌉.

40 R. Dick EECS 507




Case 1 II

I.e., the maximum execution time of Task 2 is the period of Task 2 minus thetotal execution time of instances of Task 1 released within Task 2’s period.

41 R. Dick EECS 507




Case 1 III

In this case,

U = U1 + U2

=C1

T1+

C2,max

T2

=C1

T1+

T2 − C1

⌈T2

T1

⌉T2

=C1

T1+ 1−

C1

⌈T2

T1

⌉T2

= 1 + C1

(1

T1− 1

T2

⌈T2

T1

⌉)

42 R. Dick EECS 507




Case 1 IV

Is 1T1− 1

T2

⌈T2

T1

⌉≤ 0?

If T2 = T1 + ε, this is

1

T1− 1

T1 + ε

⌈T1 + ε

T1

⌉=

1

T1− 2

T1 + εwhich is less than or equal to zero.

Thus, U is monotonically nonincreasing in C1.

43 R. Dick EECS 507




Case 2 I

Instances of higher-priority tasks released before end of lower-priority taskperiod complete after end of lower-priority task period.

C1 ≥ T2 − T1

⌊T2

T1

⌋.

C2,max = T1

⌊T2

T1

⌋− C1

⌊T2

T1

⌋.

U1 = C1/T1.

U2 = C2/T2 = T1

T2

⌊T2

T1

⌋− C1

T2

⌊T2

T1

⌋.

U = U1 + U2 = T1

T2

⌊T2

T1

⌋+ C1

(1T1− 1

T2

⌊T2

T1

⌋).

44 R. Dick EECS 507




Minimal U I

C1 = T2 − T1

⌊T2

T1

⌋.

U = 1− T1

T2

(⌈T2

T1

⌉− T2

T1

)(T2

T1−⌊T2

T1

⌋).

Let I =⌊T2

T1

⌋and

f = T2

T1.

Then, U = 1− f (1−f )I+f .

To maximize U, minimize I , which can be no smaller than 1.

U = 1− f (1−f )1+f .

45 R. Dick EECS 507




Minimal U II

Differentiate to find mimima, at f =√

2− 1.

Thus, Umin = 2(√

2− 1)≈ 0.83.

Is this the minimal U? Are we done?

46 R. Dick EECS 507




Proof sketch for RMS utilization bound

Consider case in which no period exceeds twice the shortest period.

Find a pathological case: in phase

Utilization of 1 for some duration.

Any decrease in period/deadline of longest-period task will causedeadline violations.

Any increase in execution time will cause deadline violations.

47 R. Dick EECS 507





See if there is a way to increase utilization while meeting all deadlines.

Increase execution time of high-priority task.

e′i = pi+1 − pi + ε = ei + ε.

Must compensate by decreasing another execution time.

This always results in decreased utilization.

e′k = ek − ε.

U ′ − U =e′ipi

+e′kpk− ei

pi− ek

pk= ε

pi− ε

pk.

Note that pi < pk → U ′ > U.

48 R. Dick EECS 507





Same true if execution time of high-priority task reduced.

e′′i = pi+1 − pi − ε.

In this case, must increase other e or leave idle for 2 · ε.

e′′k = ek + 2ε.

U ′′ − U = 2εpk− ε

pi.

Again, pk < 2→ U ′′ > U.

Sum over execution time/period ratios.

49 R. Dick EECS 507





Get utilization as a function of adjacent task ratios.

Substitute execution times into∑n

k=1ekpk

.

Find minimum.

Extend to cases in which pn > 2 · pk .

50 R. Dick EECS 507




Notes on RMS

DMS better than or equal RMS when deadline 6= period.

Why not use slack-based?

What happens if resources are under-allocated and a deadline is missed?

51 R. Dick EECS 507




Multiprocessor breaks critical instant

P1

P2

1

2

3

4

1

3

2 4P1

P2

52 R. Dick EECS 507




Outline

1. Realtime systems





53 R. Dick EECS 507




Many options

eCos.

LynxOS.

MontaVista Linux.

QNX.

RTAI.

RTLinux.

Symbian OS.

VxWorks.

FreeRTOS.

Etc.

54 R. Dick EECS 507




Threads

Threads vs. processes: Shared vs. unshared resources.

OS impact: Windows vs. Linux.

Hardware impact: MMU.

55 R. Dick EECS 507




Threads vs. processes

Threads: Low context switch overhead.

Threads: Sometimes the only real option, depending on hardware.

Processes: Safer, when hardware provides support.

Processes: Can have better performance when IPC limited.

56 R. Dick EECS 507




Software implementation of schedulers

TinyOS.

Light-weight threading executive.

µC/OS-II.

Linux.

Static list scheduler.

57 R. Dick EECS 507




TinyOS

Most behavior event-driven.

High rate → livelock.

Research schedulers exist.

58 R. Dick EECS 507




BD threads

Brian Dean: Microcontroller hacker.

Simple priority-based thread scheduling executive.

Tiny footprint (fine for AVR).

Low overhead.

No MMU requirements.

59 R. Dick EECS 507




µC/OS-II

Similar to BD threads.

More flexible.

Bigger footprint.

60 R. Dick EECS 507




Old Linux scheduler

Single run queue.

O (n) scheduling operation.

Allows dynamic goodness function.

61 R. Dick EECS 507




O (1) scheduler in Linux 2.6+

Written by Ingo Molnar.

Splits run queue into two queues prioritized by goodness.

Requires static goodness function.

No reliance on running process.

Compatible with preemptable kernel.

62 R. Dick EECS 507




O (log n) scheduler in Linux 2.6.23+

Written by Ingo Molnar.

Used red-black tree to maintain accumulated task times.

Always schedules task with least accumulated time.

Weights accumulated time based on priority.

63 R. Dick EECS 507




Real-time Linux

Run Linux as process under real-time executive.

Complicated programming model.

RTAI (Real-Time Application Interface) attempts to simplify.

Colleagues still have problems at > 18 kHz control period.

64 R. Dick EECS 507




Real-time operating systems

Embedded vs. real-time.

Dynamic memory allocation.

Schedulers: General-purpose vs. real-time.

Timers and clocks: Relationship with HW.

65 R. Dick EECS 507




Real-time operating systems

Interaction between HW and SW.

Rapid response to interrupts.

HW interface abstraction.

Interaction between different tasks.

Communication.

Synchronization.

Multitasking

Ideally fully preemptive.

Priority-based scheduling.

Fast context switching.

Support for real-time clock.

66 R. Dick EECS 507




General-purpose OS stress

Good average-case behavior.

Providing many services.

Support for a large number of hardware devices.

67 R. Dick EECS 507




RTOSs stress

Predictable service execution times.

Predictable scheduling.

Good worst-case behavior.

Low memory usage.

Speed.

Simplicity.

68 R. Dick EECS 507




Predictability

General-purpose computer architecture focuses on average-case.

Caches.

Prefetching.

Speculative execution.

Real-time embedded systems need predictability.

Disabling or locking caches is common.

Careful evaluation of worst-case is essential.

Specialized or static memory management common.

69 R. Dick EECS 507




RTOS overview

Memorymanager

BasicIO

managerTask

IPC

ISRTimer

etc.

ABSMPEGencoding

Applications

RTOSservices

Communication

Micro−browser

Messagecomposer Database

Organizer

Tasks

Hardware

Other hardware

Network interface

Processor Memory

Timer

70 R. Dick EECS 507




Outline

1. Realtime systems





71 R. Dick EECS 507




Cyber-physical systems

Computer systems involving interaction with the physical world.

Sensing →

Signal processing →

Analysis and control →

Actuation.

All tied together via models and hardware/software implementations.

72 R. Dick EECS 507




Cyber-physical systems disciplines

Modeling

and

specification

Embedded

system

design

Real−time

systems

Control

systems

Digital

signal

processing

Cyber−

physical

systems

Robotics

73 R. Dick EECS 507




Relationship with IoT

Substantial overlap.

IoT systems arguably needn’t involve control theory and actuation, althoughthey often do.

CPS need not involve slow, unreliable networks, although they often do.

74 R. Dick EECS 507




Outline

1. Realtime systems





75 R. Dick EECS 507





18 February: L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P. Dick, Z. M.Mao, and L. Yang, “Accurate online power estimation and automatic batterybehavior based power model generation for smartphones,” in Proc. Int. Conf.Hardware/Software Codesign and System Synthesis, Oct. 2010, pp. 105–114.

Deadline change: You can delay your project proposal revision from 12 to 15February if you need to speak with me first.

76 R. Dick EECS 507

http://robertdick.org/publications/zhang10oct.html

http://robertdick.org/publications/zhang10oct.html

Documents

Introduction to Embedded Systems Research: Scheduling ...ziyang.eecs.umich.edu/~dickrp/iesr/lectures/l6.pdfIntroduction to Embedded Systems Research: Scheduling, embedded OSs, and