Dedicated Systems Experts 2005 - Martin TIMMERMAN p. 1 OS: the state of the art Module 2 Scheduling and memory management

Dedicated Systems Experts 2005 - Martin TIMMERMAN p. 1

OS: the state of the art

Module 2Scheduling and memory

management

Dedicated Systems Experts – 2005 – Martin TIMMERMAN p. 2

Content of module 2

a. Introduction: what is an operating system

b. RTOS architecturesc. Schedulingd. Memory Managemente. Conclusions


Documentation

• This presentation• Evaluation reports

– http://www.dedicated-systems.com

• This course website– http://vub.dedicated-systems.com– Username: vubuser– Code: vubdse1!


www.dedicated-systems.com






OS: a definition

• GENERAL PURPOSE OS (GPOS): – A GPOS is a collection of programs that

acts as an intermediary between the hardware and its user(s), providing a high-level interface to low level hardware resources, such as the CPU, memory, and I/O devices.


GPOS: PURPOSE

• To provide an environment with facilities and services that make the use of the hardware– Convenient – Efficient– Safe– Secure

• Sharing of resources among users and/or programs


GPOS: facilities & services

• Memory management• Process management• Communication facilities• A command language interpreter or

GUI• A file system• ....


OS TYPES

data-base

off-line

personalcomputing

Timesharing

on-line

batch remote batch

user-Program-

mable

non-Program-

mable

multi-user single-user

Responserequirements

Protection Requirements

real-time

In 1980


no compilers time software shared multi-user

resident monitors

Migration of OS concepts and features

1950 1960 1970 1980 1990

no compilers time software shared multi-user

batch resident

monitors

Minicomputers

MULTICS

UNIX

no compilers interactive software multi-user

resident . monitors .

UNIXMicrocomputers

Mainframes

1940

distributedsystems

2000


GPOS - RTOS

• GPOS– Multiple applications on one system– Maximum resource usage– Average performance is important

• RTOS– A single application on a system– Reliably– Predictability = time constraints on

individual events


Real-Time OS: too many or too few?

• An enormous quantity of RTOS are available today

• Free – commercial – with/without source – experimental…

• Some are competitive, others are complementary

• The miss-choice of an RTOS may have dramatic results on a project


Some Embedded (Real-Time) OS

• AMX (KADAK)• CExecutive (JMI)• CHORUS (Jaluna C5)• CX/UX (HARRIS)• eCos• FlexOS (NOVELL)• iRMX (Intel)• LynxOS (Lynx)• Linux flavours• OSE (ENEA DATA)• OS9 (Microware)

• PDOS (Eyring Research)• (pSOS+) (WindRiver)• QNX (QNX)• Real/IX (Modcomp AEG)• SPECTRA (VRTX) (Mentor

Graphics)• SMX (Micro Digital)• SunOS (Sun)• Symbian• VXWorks (Wind River)• Windows CE• Windows XP embedded


Thesis

General purpose systems are migrating from mainframe to distributed Client-Server technologies. A Real-Time System is

distributed by nature and is using this technology for some years already.

General purpose systems are migrating from mainframe to distributed Client-Server technologies. A Real-Time System is

distributed by nature and is using this technology for some years already.

Real-Time & General Purpose OS technology is melting together.

Real-Time & General Purpose OS technology is melting together.


Scenario for the presentations (1)

RequirementRequirement

• What are the requirement for a good RTOS?


Scenario (2)

• Examples: – Of real product situations– Some examples show product problems

which are in most cases resolved by now• In new release• Except for NTe – XPe – Linux (because non

RT!)


Testing scenario


evaluation test platform• Pentium 200 MMX

– Reference platform– Not really an embedded processor– Is faster than most embedded processors

• PPC– ATX platform with MPC7410 PPC 400 MHz

• ARM9– ATX module: Integrator AP/CM920 T

• Hardware logic analyser for measurements

(10 ns resolution)– No tricks with on-boards timers– No resolution problems with these timers


Development Platforms


Pictures


Test examples

• Platform calibration– To compare results with different

processors• Performance measurements

– Thread creation, switching, deletionInterrupt latencies under load conditions Semaphore/mutex creating, release,..

• Behaviour– Queues: Task/thread, Semaphore/mutex– Application simulation

• Endurance tests


Test procedure• Starttime: Before starting an OS call write a

trace to PCI bus – capture with (PCI) analyser• Start the call• Stoptime: At the end of the call – write again

a trace to the PCI bus – capture with analyser• Do this as many times as possible – limited

to the size of the analyser trace buffer• Do the same test in different circumstances

– No other activity– A lot of other activity (processor load)

• Event = system activity between start and stop

• Eventtime = stoptime - starttime


Measurements:sample diagram

3000

3900

4800

5700

6600

7500

8400

9300

10200

11100

12000

0 10000 20000 30000 40000 50000

absolute time (µs)

even

t d

ura

tio

n (

ns)

All public tests on 200 MHz Pentium MMX motherboard platform


Measurements:histogram

1

100

10000

1000000

3000 3900 4800 5700 6600 7500 8400 9300 10200 11100 12000

time (ns)

nb

r o

f ev

ents


End of M2aIntroduction


Module 2 b:RTOS Architecture


Good RTOS – REQ: OS structure

A good RTOS needs a Client/Server architectureA good RTOS needs a Client/Server architecture


OS STRUCTURE

• Simple or monolithic structure• Layered Approach• Client/Server model


Software Layers (1)

Hardware

System software

ApplicationsImplemented in software


The RT way

Hardware

Applications

System software


Software Layers (2)

Hardware

System software

Applications

Languagetranslators

Operatingsystem

UtilityPrograms


Software Layers (3)

Hardware

System software

Applications

Kernel

Memory manager

I/O system

File manager

Short-term scheduler

Resource manager

Long-term scheduler

Command interpreter

Languagetranslators

Operatingsystem

UtilityPrograms


Monolithic OS

ApplicationProgram

ApplicationProgram

. . .

User Mode

Kernel Mode

System Services

Hardware

OperatingSystem

Procedures


Client/server OS = REQ

ClientApplication

DisplayServer

User Mode

Kernel Mode

Hardware

Microkernel

FileServer

ProcessServer

MemoryServer

NetworkServer

Send

Reply


Client/server OS: advantages

• OS components are small and self-contained

• a single server may fail and be restarted (user mode) without corrupting the rest of the OS

• different servers may run on different processors = easy distributed environments


Client/server examples

• New approach– Chorus (now Jaluna C5) (EU)– QNX neutrino = QNX 6.x (CANADA)– VxWorks 6.x ??? (US)

• Inherent (old) approach– OSE (EU)– VXWorks 5.x (US)– VRTX (US)– - ..


Good RTOS – REQ:OS architecture

Whatever architecture is used, it should be clearly documented and published.

Whatever architecture is used, it should be clearly documented and published.


Example of different architectures

• Basic NT architecture• RTX• INTIME


RTX 4.1 (version 2) their view


INtime - their view


Simplified Basic NT architecture

Hardware

HAL

NT-Kernel I/O MgrDev.Dr.

Win32

thre

ad

process

Win32

thre

ad

process

Win32

thre

ad

process

Win32

thre

ad

process


RTX - our view

Hardware

HAL


Win32

thre

ad

process

Win32

thre

adproces

s

RT-API

thre

ad

process

RT-API

Timer - irq handling

scheduler

thre

ad

process

RT-API

RIN

G 3

RIN

G 0


INtime - our view

Hardware

HAL


Win32

thre

ad

process

Win32

thre

adproces

s

NTX

thre

ad

processRT-API

scheduler

thre

ad

processRT-API

RIN

G 3

RIN

G 0

MEM

NTXdriver

NTXdriver

Timer - irq handling

process

process


End of M2bRTOS architecture


Module 2 c:Processor(s)

management: scheduling


M2c: Processor(s) Management

Single processor issues• Scheduling in general• A simple introduction to OS-

scheduling• Scheduling for RT-Systems

Multiple processor issues (later – Module x)


Scheduling in general


Scheduling in general

• Scheduling = ressource sharing• Resource

– Processor: “scheduling”– Disk: “disk scheduling”– Bus: “arbitration”– Network– ....– Human, material: “project planning”


Scheduling = Arbitration = Disk Scheduling

= Project Planning

Common Resource

Object 1

Object 2 Object 3

Object 4

all objects want to use the resource simultaneously = need for arbitration or scheduling


Scheduling

Processor

Task 1

Task 2 Task 3

Task 4

all bus masters want to use the processor simultaneously = need for scheduling


IEEE’ s Scheduler

• IEEE 610.12-1990 (standard glossary of software engineering terminology)– A computer program, usually part of an

operating system, that schedules, initiates and terminates jobs.


Arbitration

Bus

Bus Master 1

Bus Master 2 Bus Master 3

Bus Master 4

all bus masters want to use the bus simultaneously = need for arbitration


IEEE’ s Arbitration

• IEEE 959 - 1987 (SBX)– The process of determining which requested

device will gain access to a resource

• IEEE 1000 - 1987 (STEbus)– The means whereby masters compete for

control of the bus and the process by which a master is granted control of the bus.

• IEEE 1196 - 1987 (VSB)– A collection of mechanisms that allow masters

to access the bus without conflicting with each other.


Arbitration = Scheduling

• For n levels of priority• (Preemptive) Priority (for Real-Time

Systems)– n > n-1 > .......... > 1

• Round Robin Select– n = n-1 = .......... = 1

• Mixed modes

nn-11

2

i

VMEbusVMEbus

levelslevels

44

PCIPCI # slots# slots

RTOSRTOS 256256


Disk Scheduling

Disk

AccesRequest

1Acces

Request 2

AccesRequest

3

AccesRequest

4

different requesters want to use the disk simultaneously = need for scheduling


JOB and PROCESSOR SCHEDULING

• Scheduling levels• Scheduling objectives• Scheduling criteria• Pre-emptive vs Non pre-emptive • The interval timer• Priorities• Discussion of scheduling methods


Scheduling levels Jobs waiting for entry

Jobs waiting

for initiation

Suspendedprocesseswaiting foractivation

Activeprocesses

Running processes

Completed

Complete

DispatchBlock or timerout

Active Suspend

Job initiation

Job entry

High-level scheduling

Intermediate-level scheduling

Low-level scheduling

Running

Ready Blocked

Block

Timerrunout

Dispatch

Wakeup


Scheduling levels - GPOS• High-level scheduling = job scheduling

– job or admission scheduling– compete for the resources of the system– jobs become processes or groups of processes

• Intermediate-level scheduling– which process competes for the CPU(s)– is a buffer between admission of jobs and

assigning them to the CPU• Low-level scheduling = process/thread

scheduling– performed by the dispatcher which is all the

time in primary storage– which ready process will be assigned the CPU


Possible Scheduling objectives• Fair• Maximize throughput• Maximum number of interactive users• Be predictable and respect deadlines• Minimize overhead• Balance resource use• Balance response and utilization• Avoid indefinite postponement• Enforce priorities• Preference to processes holding key resources• Better service to P with desirable behavior• Graceful degradation under heavy loads


Scheduling criteria in general• Consider

– That a process can be• I/O bounded• CPU bounded• batch or interactive

– How urgent is a fast response– Process priority– how frequently a process

• is generating page faults• has been pre-empted by a higher priority process

– how much • real execution time has been received• more time is needed to finish


Processor Schedulinga simple introduction


Scheduling mechanismsa simple introduction

• Single event system• Multiple event system• Use scheduling with RR and a ticker• Use priorities• Pre-emption


Single event system

respond to event

? eventNo

Yes

Deadline = respond to event time + jitter on event detection


Multiple event system 1

respond to event A

wait forevent A

respond to event B

wait forevent B

respond to event C

wait forevent C

A B C

A, B & C ordered


Multiple event system 2

? event A1 ms

respondto

event A40 ms

? event B1 ms

respondto

event B35 ms

? event C1 ms

respondto

event C30 ms

A B C

A, B & C random

total loop time: 108 mstotal loop time: 108 ms

Y

Y

Y


•Exec times: •A: 40 ms•B: 35 ms•C: 30 ms

•Deadlines:•A: 100 ms•B & C: 150 ms


•Deadlines:•A: 100 ms•B & C: 150 ms

? event A1 ms

respondto

event A40 ms

? event B1 ms

respondto

event B35 ms

? event A1 ms

respondto

event A40 ms

? event C1 ms

respondto

event C30 ms

Y

Y

Y

YA: 40 ms C: 30 msB: 35 ms A: 40 ms

time


? event A1 ms

respondto

event A40 ms

? event B1 ms

respondto

event B35 ms

? event A1 ms

respondto

event A30 ms

? event C1 ms

respondto

event C30 ms


•Deadlines:•A: 100 ms•B: 130 ms•C: 150 ms



? event B1 ms

respondto

event B35 ms

Y

Y

Y

Y

Y


? event A1 ms

respondto

event A40 ms

? event B1 ms

respondto

event B35 ms

? event A1 ms

respondto

event A40 ms

? event C1 ms

respondto

event C30 ms





? event B1 ms

respondto

event B35 ms

Y

Y

Y

Y

Y

Total loop time:149 ms

Total loop time:149 ms


Basic ingredients for scheduling

• Ticker• A state machine concept


EXECUTIVEEXECUTIVE

Task ATask A

Task BTask B

Task CTask C

respond to event

? event No

Yes


CPUCPU

TIMER - TICKERTIMER - TICKERRepetitive Interrupt

timeX ms


A: 40 ms B: 35 ms A: 40 ms C: 30 ms

time slice: 41 ms = best solution

time

A: 40 ms C: 30 msB: 35 ms A: 40 ms

Solution with just one program

Is it better?


150170190210230250270290

2 7

12

17

22

27

32

37

42

47

52

57

Total time = f (timeslice)

Total time

timeslice


execputs taskto sleep


execwakes up

task

execwakes up

task

execute trap

instruction

execute trap

instruction

respondto

event

respondto

event

hasevent

occurred?

hasevent

occurred?

Why is it worse?

Happens occasionally




execwakes up

task

execwakes up

task

execute trap

instruction

execute trap

instruction

respondto

event

respondto

event

THE solution

BUT: who is detectiong the event??

The OS = the device driver!


EXECUTIVEEXECUTIVE

Task ATask A

Task BTask B

Task CTask C

respond to event C

respond to event B

respond to event A


Process states & transitions

Running

Ready Blocked

Block

Timer-runout

Dispatch

Wakeup


Queues – 4 processors

Running

Ready Blocked

Block

Timer-runout

Dispatch

Wakeup


Queues – 1 processors

Running

Ready Blocked

Block

Timer-runout

Dispatch

Wakeup


Different scheduling algorithms


Some scheduling mechanisms

• http://en.wikipedia.org/wiki/Category:Scheduling_algorithms

• FIFO• Round Robin• Multilevel feedback queues• Shortest job first (SJF)• Shortest remaining time


FIFO scheduling

C AB

Ready list

A CPUcompletion


Round Robin scheduling (RR)

C AB

Ready list

A CPUcompletion


Multilevel feedback queues

CPUcompletion

CPUcompletion

CPUcompletion

Level 1

Level 2

Level 3


Shortest-job-first

• non pre-emptive scheduling• waiting job with smallest estimated

run-time-to-completion is run next• requires precise knowledge of how

long a job will last• once a job is started it runs to

completion


Shortest-remaining-time

• Pre-emptive counterpart of SJF• job with shortest estimated runtime

to completion runs next• should keep track of elapsed time

(creates more overhead)


Good RTOS – REQ:A deadline scheduler

A good RTOS needs a deadline scheduling mechanism.This technology is NOT (yet?) available.

Pre-emptive scheduling is an acceptable replacementif RMA is used

A good RTOS needs a deadline scheduling mechanism.This technology is NOT (yet?) available.

Pre-emptive scheduling is an acceptable replacementif RMA is used


Deadline scheduling problem

• Precise resource requirements should be known in advance

• The system must carefully plan its resource requirements through to the deadline

• Knowledge of task execution time is needed.

• What if many deadline jobs exists together?• scheduling algorithm complexity introduces

(serious) overhead


Waiting for deadling scheduling(if ever)

• Pre-emptive priority scheduling• Rate Monotonic Analysis• Earliest deadline• Least slack• ..• Time triggered


TASK A (40)

TASK B (35)

ISR A ISR B

TASK C (30)

timeslice: 25

Priority Scheduling

time


TASK A (40)

TASK B (35)

ISR A ISR B

TASK C (30)

timeslice: 25

Pre-emptive Priority Scheduling

time


TASK A (40)

TASK B (35)

ISR B ISR A

TASK C (30)

timeslice: 25

Pre-emptive Priority Scheduling

time


Rate-Monotonic Scheduling

• Liu and Layland [1973]: RMS = optimal fixed-priority scheduling– If a successful scheduling for the RMS cannot

be found, then no other fixed priority mechanism will avail.

• The higher the request rate, the higher the priority assigned to the process request

• As long as the processor utilisation remains BELOW a certain level RMS will assure the meeting of the deadlines of the tasks


Static RMS

• the process set is schedulable by the static rate monotonic priority assignment scheme if

u = ci . fi n (21/n - 1)u = ci . fi n (21/n - 1)n

i = 1

n max (u) 1 1 2 .83 3 .78 4 .76 5 .74 10 .72 100 .701000 .69

n max (u) 1 1 2 .83 3 .78 4 .76 5 .74 10 .72 100 .701000 .69

u: processor utilisation ci : task period fi : tasks frequencyn: number of tasks

u: processor utilisation ci : task period fi : tasks frequencyn: number of tasks


Periodic tasks: example 1Task Period ExectimeCY_1 2 s 1 sCY_2 3 s .9 s

Total 6 s 4.8 s: 80 %

CY_1: Pr: 110

CY_2: Pr: 100

CY_1: Pr: 100

CY_2: Pr: 110

runwaitidle


Periodic tasks: example 2Task Period ExectimeCY_1 2 s 1 sCY_2 3 s 1.1 s

Total 6 s 5.2 s: 87%

CY_1: Pr: 100

CY_2: Pr: 110

CY_1: Pr: 110

CY_2: Pr: 100


Periodic tasks: example 3Task Period ExectimeCY_1 2 s 1 sCY_2 3 s 1.1 s

Total 6 s 5.2 s: 87%

CY_1: Pr: 110

CY_2: Pr: 100

CY_2: Pr: 100CY_2: Pr: 120

Change priorities dynamically


Periodic + non periodic tasks

• earliest deadline (d)• least slack (minimal laxity)


Earliest Deadline• http://en.wikipedia.org/wiki/Earliest_deadline_first_schedulin

g

• the process set is schedulable on a single processor by the dynamic earliest deadline scheme if

ci . fi n

i = 1

• ci : the computation time of task i• fi : the task's frequency


Least Slack Time• http://en.wikipedia.org/wiki/Least_slack_time_scheduling

• slack (Pi , t) = max (di - ci - t , 0)

• optimal in single processor systems only


Some supplementary issues

• Queue response predictability• Cache introduces un-predictability• Hard RT today with TTP


Scheduling queues

head

tail

registers

PCB aPCB a

registers

PCB bPCB b

readyqueue

queue header

For predictability: thread switch time should be independent of the number of threads waiting in the

queue.

Always order queue when a thread goes into it! High priority thread goes in top of it.


Cache???

• RMA is based on the availability of a fixed processor performance capability

• Cache, pipelining & other mechanism provides us with a variable performance engine. They give an AVERAGE enhancement of processor performanceToday - there is no real solution how to deal with this!


TTA & TTP

• Time Triggered Architecture• Time Triggered Protocol• Time Triggered OS

– OSEK– OSEKtime

• http://www.ttagroup.org/• http://www.tttech.com




Good RTOS – REQ:have enough thread

priority levels

A good RTOS needs enough thread priority levels (> 128) so that the

application of RMA or similar theories is easy.

A good RTOS needs enough thread priority levels (> 128) so that the

application of RMA or similar theories is easy.


NT priority levels

Not enoughLevels for a serious real-time design!

Not enoughLevels for a serious real-time design!


CE 2.0 Fixed Priority levels

•0-1 (interrupt level)– real-time processing and device drivers–0: time-critical - no time slicing

•2-4 (main level)–normal applications

•5-7 (idle level)–non RT threads–pre-emption available

•same priority level: round-robin

Not enough levels for a serious real-time design!

Not enough levels for a serious real-time design!


CE 3.0 Fixed Priority levels

•0-246 (real-time priority interrupt level)

•247-255 (system level)•same priority level: round-robin


QNX

• 32 levels• May be just enough!?


End of Scheduling


Module 2 d:Memory management


M2d: Storage management

As some people use non-RT systems for embedded applications, we are obliged to study both GPOS and RTOS memory management techniques.

• Memory Management (Real storage)• Virtual Memory (Virtual storage)• Storage in RT-Systems


MEMORY MANAGEMENT

• Background• Swapping• Single-Partition Allocation• Multiple-Partition Allocation• Multiple Base Registers• Paging• Segmentation• Paged Segmentation


Memory Management: intro

• multiple processes: share memory• different ways of managing memory

– primitive bare machine– paging– segmentation

• selection of memory management = hardware design issue


Background

• Memory is central to the operation of a modern computer system

• In this section we may ignore HOW a memory address is generated by a program via the CPU or any other device

• We are only interested in the sequence of memory addresses generated by the running program

• In a first approach: the whole program in memory to be able to run


Background

• Address Binding• Dynamic Loading• Dynamic Linking• Overlays


B: Address Binding 1

sourceprogram

sourceprogram

objectmodule

objectmodule

compiler orassembler


compile time



objectmodule

objectmodule

loadmodule

loadmodule

linkageeditor

linkageeditor

load time

otherobjectmodule

otherobjectmodule



loadmodule

loadmodule

inmemory

inmemoryloaderloader

execution time(run time)

load time

systemlibrary

systemlibrary

dynamicallyloaded system

library


library


Address Binding during development

sourceprogram

sourceprogram

objectmodule

objectmodule



other objectmodule

other objectmodule

loadmodule

loadmodule

linkageeditor

linkageeditor

objectlibrarymodule

objectlibrarymodule

inmemory

inmemory

loaderloader

systemlibrary

systemlibrary


library


library

residentsystemlibrary

residentsystemlibrary


Dynamic loading

• loading a routine when needed• routines are kept on disk• advantages:

– unused routines are never loaded– no special support from OS

• examples: error routines

NON-RT


Dynamic linking

• example: having the library loaded in memory all the time

• advantage:– memory usage– easy replacement of library by new one

(with less bugs)

• other name: shared libraries

RT-OK


Overlays

• problem: limitation of program size (historical issue)

symboltable

commonroutines

overlaydriver

pass 2pass 1

20K

30K

10K 80K70K

NON-RT


Swapping

• swapping out to a backing store

operatingsystem

userspace

processP1

processP2

swap out

swap in

NON-RT


Swapping

• swapping back to the same place or not depending on the address binding

• backing store is fast disk• context switch time may be very high if

swapping is needed• problem: swapping a process with pending

I/O– solution 1: wait for I/O completion– solution 2: I/O via OS buffers

• today swapping is only used in very few systems

NON-RT


Single-partition-allocation 1• simple memory management = NONE

– user has complete control over entire memory• advantages:

– maximum flexibility to the user– maximum simplicity and minimum cost– no need for special hardware– no real need for OS software

• limitations– no service– OS has no control over interrupts– no mechanism to process system calls or

errors– no space for multi-programming

RT-OK


Single-partition allocation 2

• divide memory in 2 partitions– one for the user– one for the OS (if used) OS

user

0

512K RT-OK


SPA: memory protection

CPUCPU >=>= <<

basebase base + limitbase + limit

memorymemory

trap to OS monitor - addressing error

address yes yes

no no

RT-OK


SPA: loading problem

• user program does not start at 0• what if OS uses transient code

– OS code size changes during execution– Transient code is not anymore needed

with modern processors


SPA: loading - solution 1

• process loaded in high memory

operatingsystem

user

0

512K


SPA: loading - solution 2

• dynamic relocation:

• user thinks the process runs in location 0

CPUCPU++

1400014000

base register

memorymemorylogical

addressphysicaladdress

346 14346

RT-OK


Multiple-Partition-Allocation

• multi-programming• fixed-sized partitions

– example: IBM OS/360operatingsystem

2160K

2560K

400K

0

Job Queue

Process memory TimeP1 600K 10P2 1000K 5P3 300K 20P4 700K 8P5 500K 15

Job Queue

Process memory TimeP1 600K 10P2 1000K 5P3 300K 20P4 700K 8P5 500K 15


P1

P2

P3

P4

P5


operatingsystem

P5

P4

P3

2560K

2300K

2000K

1700K

1000K

900K

400K

0

operatingsystem

P1

P4

P3

2560K

2300K

2000K

1700K

1000K

400K

0

operatingsystem

P1

P3

2560K

2300K

2000K

1000K

400K

0

operatingsystem

P1

P2

P3

2560K

2300K

2000K

1000K

400K

0

operatingsystem

P4

P3

2560K

2300K

2000K

1700K

1000K

400K

0

External fragmentation & compaction


MPA: dynamic storage allocation

• First-fit– first hole that is big enough

• Best-fit– smallest hole that is big enough

• Worst-fit– largest hole


MPA: external fragmentation

• enough space is left but is not contiguous

• one third of memory may be unusable

EXTERNAL FRAGMENTATION


MPA: memory protection

CPUCPU << ++

limitlimit base base

memorymemory

trap to OS monitor - addressing error

logicaladdress yes

no

RT-OK


MPA: internal fragmentation

operatingsystem

P7

P43

next requestfor 17.000 bytes

hole of18.000 bytes

INTERNAL FRAGMENTATION


MPA: compaction

• shuffle all free memory together in one large block

• combine compaction with swapping to make it work

NON-RT


operatingsystem

P5

P4

P3

2560K

2300K

2000K

1700K

1000K

900K

400K

0

operatingsystem

P5

P4

P3

660K

2560K

1900K

1600K

900K

400K

0

NON-RT


operatingsystem

P1

P2

400K

2100K

1900K

1500K

1000K

600K

500K

300K

0

P3

300K

1200K

P4

operatingsystem

P1

P2

2100K

800K

600K

500K

300K

0

P3

1200K

P4

900K

moved 600K

operatingsystem

P1

P2

2100K

1000K

600K

500K

300K

0

P3

1200K

P4

900K

moved 400K

operatingsystem

P1

P2

900K

2100K

1900K

1500K

600K

500K

300K

0

P3

P4

moved 200K NON-RT


Multiple Base Registers

• problem of variable-sized partition scheme is external fragmentation

• solution: break down the memory a process needs into several parts

• multiple base registers per process must be provided to do logical to physical address translation


MBR: solution 1

• memory divided into 2 disjoint parts by using the high order address bit

• use 2 pairs of base registers• compilers and assemblers put

– read-only values in high memory– variables in low memory

• mechanism permits shared use of read-only segments


MBR: solution 2

• separate a program into 2 parts: code and data

• programs may be shared– compilers– editors– ...


PAGING

• problem: external fragmentation• solution:

– Compaction - – paging

• paging can also be used on the backing store (= virtual memory)


pp ff

Paging Hardware

CPUCPUpp dd ff dd

physicalmemory

physicalmemory

logical address physical address

012345678

012345678

abcdefghi

abcdefghi


P: hardware 2

• page size– 512 to 2048 bytes per page– depends on the number of bits of “d”– = table of base registers

page 0page 0

page 1page 1

page 2page 2

page 3page 3

page 0page 0

page 2page 2

page 1page 1

page 3page 3logical memory

physical memory

00

11

22

33

1 1

44

33

77

1

4

3

7

0

2

5

6


new processpage table

Paging mechanism

free frame list1413182015

13

14

15

16

17

18

19

20

21

new processpage 0page 1page 2page 3

free frame list15 page 1

page 0

page 2

page 3

13

14

15

16

17

18

19

20

21

new processpage 0page 1page 2page 3

0

1

2

3

14

13

18

20


P: implementation of page table

• performance issue• dedicated registers

– high speed logic– part of the context

• in main memory– via page-table base register for fast context

switch– speed reduction by 2

• special small hardware memory– called associative registers or translation look-

aside buffers (TLBs)– hit ratio problem

SLOWER-RT-OK


pp ff

CPUCPUpp dd

012345678

012345678

ff dd

physicalmemory

physicalmemory


abcdefghi

abcdefghi

associative map

RT-OK


pp ff

pp ff

CPUCPUpp dd

02358

02358

ff dd

physicalmemory

physicalmemory


acdfi

acdfi

associative map012345678

012345678

abcdefghi

abcdefghi

++

address ofpage table b

address ofpage table b

PT origin R

b

only if no matchin assoc. map

NON-RT ?


P: shared pages

• if code re-entrant– non self modifying code!– also called pure code

ed 1ed 1

ed 2ed 2

ed 3ed 3

data 1data 1

33

44

66

11

process P1 PT

ed 1ed 1

ed 2ed 2

ed 3ed 3

data 3data 3

33

44

66

22

process P3 PT

ed 1ed 1

ed 2ed 2

ed 3ed 3

data 2data 2

33

44

66

77

process P2 PT

data 1

data 3

ed 1

ed 2

ed 3

data 2

0

1

2

3

4

5

6

7

8


P: protection

• protection bits associated with each frame– read– write– read-only– read-write– execute only

• protection via page-table length register– limited number of pages given to a process

(not all pages are possible)– if other pages used: bus error for OS

RT-OK


P: two views of memory

• user’s view - OS view• logical - physical address• logical to physical address translation for

I/O operations

• Paging solves problem of external fragmentation but creates internal fragmentation!

• Page size is small. Many pages needed. Associated Map is limited. RT-problem


SEGMENTATION

• User’s view of memory– user does not think of memory as a

linear array

subroutinestack

mainprogram

symboltable


Segmentation 2

• segmentation supports user’s view• example: Pascal compiler

– global variables– the procedure call stack– the programs itself– the local variables of each procedure and

function

• segments are numbered• user refers to a piece of code or data via a

segment number and an offset in the segment


S: hardware

CPUCPU (s,d)

limitlimit basebase

<<++

Physical memory

Physical memory

segment table

yes

no

address error trapRT-OK


lim

1000

4001100

1000

subroutinestack

mainprogram

symboltable

segm 0

segm 3

segm 2

segm 0

segm 5

base

1400

43003200

4700

segment table

segment 0

segment 3

segment 2

segment 5

1400

012345

2400

3200

4300

4700

5700


S: implementation of segment tables

• Segment table – part of the context (will be in Task Control Block

• Context is larger – thread switching time is higher = slower RT-OK


S: protection and sharing

• protection: corresponds better to the user idea– read– write – read-only– execute only

• sharing– at the segment level: any information can be

shared if it is defined at the segment level– examples: share entire program, share a

subroutine, share a data portion


S: fragmentation

• a lot of external fragmentation– to be reduced by using smaller

segments– but then more segment table space to

be lost + performance degradation

• no internal fragmentation


Paged Segmentation

• 68000 family: flat address space– First MMU was external chip

(segmented)– Then new external chip (paged)– 68030: paged MMU inside the chip

• 8086 family: segmentation– Created problem with OS2– Todays’ solution for INTEL processors:

page the segments


VIRTUAL MEMORY

• Motivation• Demand Paging• Performance of Demand Paging• Page replacement• Page replacement algorithms• Allocation of Frames• Trashing• Other Considerations• Demand Segmentation


VM: motivation

• in previous chapter: process entirely in memory• the entire program is not always needed in

memory– error code rarely used– over consumption of memory for arrays, lists etc..– some program options are never used (by most users)

• not all the time needed in memory:– program larger than physical memory– each user takes less physical memory– less I/O to load and swap each program into memory

• overlay is not anymore needed


VM: Demand Paging

0 1 2 3

4 5 6 7

8 9 10 11

12 13 14 15

16 17 18 19

20 21 22 23

page out

page in

main memory


VM: Demand Paging 2

• hardware support– valid-invalid bit in page table


0 1 2 3

4 A5 B6 C7

D8 E9 F10 11

12 13 14 15

16 17 18 19

20 21 22 23

A

B

C

D

E

F

G

H

0

1

2

3

4

5

6

7

logical memory

A

C

0

1

2

3

4

5

6

7

8

F9

10

11

0

1

2

3

4

6

v

i

v

i

4

5

6

7

9

i

v

i

i

page table

physical memory


load M

i

OS

free frame

physical mem

page table

1: reference

2: trap

3: page is on disk

4: get missing page

5: reset page table

6: restart inst

NON-RT!!


VM: performance & demand paging

• following sequence occurs– trap to OS– save the user registers and process state– determine that the interrupt was a page fault– check that page ref was legal and locate page on disk– issue read from disk to a free frame

• wait in queue for this device until read is serviced• wait for device seek and/or latency time• begin transfer of the page to free frame

– while waiting, allocate CPU to other user (optional CPU scheduling)

– disk I/O completion– save registers and process state for the other user– determine the interrupt was from disk– correct page tables and other tables– wait for CPU to be allocated to this process again– restore user registers, process state and new page table, then

resume the interrupted instructionNON-RT


VM: page replacement

• limit the number of pages in memory for one user

• replace an old (non used) page with a new one

• Different page replacement algorithms (pm)

• problem of how many frames a process gets

• a process is trashing if it spends more time paging than executingNON-RT


VM: other considerations

• page size (hardware issue)• program structure and behaviour

under paging is NON-RT• ......


VM: Demand segmentation

• invented especially for the 80286 not including page features

• used by OS/2


Good RTOS – REQ:Predictable Mem Mgt

A good RTOS needs a predictable memory mgt system.It will therefore be as simple as possible.

No memory leaks are accepted. Garbage collection is damned.Memory protection becomes an important issue.

If virtual memory is used, firm memory locking should be possible.

A good RTOS needs a predictable memory mgt system.It will therefore be as simple as possible.

No memory leaks are accepted. Garbage collection is damned.Memory protection becomes an important issue.

If virtual memory is used, firm memory locking should be possible.


MM in RTS

• performance issue– CPU power used for MM– if MMU is used outside processor: 10%

lost– if MMU inside processor 3% lost– MMU: protection against programmer’s

errors

• predictability issue– ask for memory - when do I get it, if I get

it!


Mem Mgt Conclusions for RT

• Never usable• Not used• Sometimes used• Always used


Never use-able in RTS

• Dynamic loading of DLL.• Virtual memory on disk.• Compaction or garbage collection

due to external fragmentation.• ..


Not Used in RTS

• Dynamic relocation via an MMU• Instead good CROSS compilers are

used generating “pure code” and position independent code (PIC)

• But could be used in slower RT systems


Sometimes Used in RTS

• Protection of segments via an MMU• Use of paging MMU is difficult due to

the large number of pages involved• Used in application where security is

important– Nuclear power plant control– Telecom billing systems


Always Used in RTS

• KISS (Keep It Simple and Stupid) • Static memory allocation • Minimal Dynamic Memory Allocation

– Try to allocate fixed size areas!


Dynamic Paging & RTwithout MMU

2K 5K

5K

2K

2K

2K

2K

2K

2K

7K

7K

Pools subdivided in blocks


Naming in RTOS

PartitionsPools

Regionssubdivided in

BlocksBuffers

Segments


Dynamic paging in RTS with segmented MMU

2K 5K

5K

2K

2K

2K

2K

2K

2K

7K

7K

• use segmented MMU• group segments in pools• never render pools to the system• segment used by task should be part

of the context


Dynamic paging in RTS with paged MMU

• associative map = part of the context

• larger than 2K pages indicated• a lot of internal fragmentation• difficult to use


Take Care

• Object oriented languages are difficult to use due to the dynamic behavior of the memory scheme.

• Forget C++ and Java for HARD real-time systems (for time being?) !!!!!!Just stick to C.

• If you use a non-RT OS with virtual memory management for (soft) RT applications, don’t forget to LOCK the (soft) RT tasks in memory.


Memory Leaks

• Some OS do not release all memory.• Garbage is building up – you need to

restart the system in order to “clean memory”


Good RTOS – REQ:known memory footprint

The memory footprint should be knowfor different configurations.

The memory footprint should be knowfor different configurations.


CE Memory Footprint

• Minimum:– low end system

• kernel + communications + stacks - no display + application

– 500 KB ROM - 350 KB RAM

• Typical footprint– Handheld PC– 2 MB ROM - 512 KB RAM


End ofRTOS Memory management


Module 2 Conclusions

Documents

Dedicated Systems Experts 2005 - Martin TIMMERMAN p. 1 OS: the state of the art Module 2 Scheduling and memory management