You are on page 1of 54

YZUCSE SYSLAB

CS512 Embedded RTOS


Embedded RTOS
Embedded RTOS
Memory Management
Memory Management
C.-Z. Yang
http://syslab.cse.yzu.edu.tw/~czyang
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 2
Background
Background
Program must be brought into memory and placed
within a process for it to be run.
Binding of Instructions and Data to Memory
Compile time: If memory location known a priori,
absolute code can be generated; must recompile code if
starting location changes.
Load time: Must generate relocatable code if memory
location is not known at compile time.
Execution time: Binding delayed until run time if the
process can be moved during its execution from one
memory segment to another. Need hardware support for
address maps (e.g., base and limit registers)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 3
Logical vs. Physical Address
Logical vs. Physical Address
Space
Space
The concept of a logical address space that is
bound to a separate physical address space is
central to proper memory management.
Logical address generated by the CPU; also referred to
as virtual address.
Physical address address seen by the memory unit.
Logical and physical addresses are the same in
compile-time and load-time address-binding
schemes; logical (virtual) and physical addresses
differ in execution-time address-binding scheme.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 4
Memory
Memory
-
-
Management Unit (
Management Unit (
MMU
MMU
)
)
Hardware device that maps virtual to physical
address. Translates the virtual address to a
physical address for each memory access(many
commercial RTOSes do not support)
In MMU scheme, the value in the relocation
register is added to every address generated by a
user process at the time it is sent to memory.
The user program deals with logical addresses; it
never sees the real physical addresses.
Provides memory protection
whether the page contains code or data,
whether the page is readable, writable, executable, or a
combination of these
whether the page can be accessed when the CPU is not in
privileged execution mode, accessed only when the CPU is in
privileged mode, or both.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 5
Contiguous Allocation
Contiguous Allocation
Main memory usually into two partitions:
Resident operating system, usually held in low memory
with interrupt vector.
User processes then held in high memory.
Single-partition allocation
Relocation-register scheme used to protect user
processes from each other, and from changing operating-
system code and data.
Relocation register contains value of smallest physical
address; limit register contains range of logical
addresses each logical address must be less than the
limit register.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 6
Hardware Support for Relocation
Hardware Support for Relocation
and Limit Registers
and Limit Registers
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 7
Contiguous Allocation (Cont.)
Contiguous Allocation (Cont.)
Multiple-partition allocation
Hole block of available memory; holes of
various size are scattered throughout memory.
When a process arrives, it is allocated memory
from a hole large enough to accommodate it.
Operating system maintains information about:
a) allocated partitions
b) free partitions (hole)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 8
Multiple
Multiple
-
-
partition allocation
partition allocation
OS
process 5
process 8
process 2
OS
process 5
process 2
OS
process 5
process 2
OS
process 5
process 9
process 2
process 9
process 10
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 9
Dynamic Storage
Dynamic Storage
-
-
Allocation
Allocation
Problem
Problem
How to satisfy a request of size n from a list of
free holes.
First-fit: Allocate the first hole that is big enough.
Best-fit: Allocate the smallest hole that is big enough;
must search entire list, unless ordered by size. Produces
the smallest leftover hole.
Worst-fit: Allocate the largest hole; must also search
entire list. Produces the largest leftover hole.
First-fit and best-fit better than worst-fit in
terms of speed and storage utilization.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 10
Fragmentation
Fragmentation
External Fragmentation total memory space
exists to satisfy a request, but it is not contiguous.
Internal Fragmentation allocated memory may
be slightly larger than requested memory; this
size difference is memory internal to a partition,
but not being used.
Reduce external fragmentation by compaction
Shuffle memory contents to place all free memory
together in one large block.
Compaction is possible only if relocation is dynamic, and is
done at execution time.
I/O problem
Latch job in memory while it is involved in I/O.
Do I/O only into OS buffers.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 11
Paging
Paging
Logical address space of a process can be
noncontiguous; process is allocated physical
memory whenever the latter is available.
Divide physical memory into fixed-sized blocks
called frames (size is power of 2, between 512
bytes and 8192 bytes).
Divide logical memory into blocks of same size
called pages.
Keep track of all free frames.
To run a program of size n pages, need to find n
free frames and load program.
Set up a page table to translate logical to physical
addresses.
Internal fragmentation.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 12
Address Translation Scheme
Address Translation Scheme
Address generated by CPU is divided into:
Page number (p) used as an index into a page
table which contains base address of each page
in physical memory.
Page offset (d) combined with base address
to define the physical memory address that is
sent to the memory unit.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 13
Address Translation
Address Translation
Architecture
Architecture
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 14
Paging Example
Paging Example
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 15
Free Frames
Free Frames
Before allocation After allocation
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 16
Paging Hardware With TLB
Paging Hardware With TLB
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 17
Memory Protection
Memory Protection
Memory protection implemented by
associating protection bit with each frame.
Valid-invalid bit attached to each entry in
the page table:
valid indicates that the associated page is in
the process logical address space, and is thus a
legal page.
invalid indicates that the page is not in the
process logical address space.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 18
Valid (v) or Invalid (i) Bit In A
Valid (v) or Invalid (i) Bit In A
Page Table
Page Table
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 19
Shared Pages
Shared Pages
Shared code
One copy of read-only (reentrant) code shared
among processes (i.e., text editors, compilers,
window systems).
Shared code must appear in same location in
the logical address space of all processes.
Private code and data
Each process keeps a separate copy of the code
and data.
The pages for the private code and data can
appear anywhere in the logical address space.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 20
Shared Pages Example
Shared Pages Example
YZUCSE SYSLAB
CS512 Embedded RTOS
M
M
emory Management in
emory Management in
Embedded Systems
Embedded Systems
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 22
M
M
emory Management in
emory Management in
Embedded Systems
Embedded Systems
Embedded systems developers commonly
implement custom memory-management
facilities on top of what the underlying
RTOS provides
Understanding memory management is
therefore an important aspect
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 23
Common Requirements
Common Requirements
Regardless of the type of embedded
system, the requirements placed on a
memory management system
Minimal fragmentation
Minimal management overhead
Deterministic allocation time
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 24
Common Memory Types in
Common Memory Types in
Embedded Systems
Embedded Systems
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 25
Working with Flash Memory (1/2)
Working with Flash Memory (1/2)
Reading data from a Flash memory is fast
and is not all that different from reading
from any other memory device.
The erase and write cycles take longer than the
read cycle. So if a read is attempted in the
middle of one of those operations, the result
will be either delayed or incorrect, depending
on the device.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 26
Working with Flash Memory
Working with Flash Memory
(2/2)
(2/2)
Writing data to a Flash is much harder. Three
factors make writes difficult.
each memory location must be erased before it can be
rewritten.
only one sector, or block, of the device can be erased at
a time; it is impossible to erase a single byte.
The size of an individual sector varies by device
the process of erasing the old data and writing the new
varies from one manufacturer to another and is usually
rather complicated.
it is usually best to add a layer of software to make the
Flash memory easier to use. If implemented, this hardware-
specific layer of software is usually called the Flash driver.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 27
Flash Drivers
Flash Drivers
Because it can be difficult to write data to the Flash device, it
often makes sense to create a Flash driver.
The purpose of the Flash driver is to hide the details of a specific
chip from the rest of the software.
This driver should present a simple application programming
interface (API) consisting of the erase and write operations.
Because the Flash memory provides nonvolatile storage that is also
rewriteable, it can be thought of as similar to any other secondary
storage system, such as a hard drive.
In the filesystem case, the functions provided by the driver would be
more file-oriented.
Standard filesystem functions like open, close, read, and write provide
a good starting point for the driver's programming interface.
The underlying filesystem structure can be as simple or complex as your
system requires.
A well-understood format like the File Allocation Table (FAT) structure
used by DOS is good enough for most embedded projects.
YZUCSE SYSLAB
CS512 Embedded RTOS
Dynamic Memory
Dynamic Memory
Allocation
Allocation
in Embedded Systems
in Embedded Systems
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 29
Dynamic Memory Allocation
Dynamic Memory Allocation
in Embedded Systems
in Embedded Systems
The program code, program data, and
system stack occupy the physical memory
after program initialization completes
The kernel uses the remaining physical
memory for dynamic memory allocation.
heap
Contiguous vs. non-contiguous block of
physical memory
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 30
Memory Control Block
Memory Control Block
Maintains internal information for a heap in
a reserved memory area
The starting address of the physical memory
block used for dynamic memory allocation
The size of this physical memory block
Allocation table indicates which memory areas
are in use, which memory areas are free
The size of each free region
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 31
Typical Implementation
Typical Implementation
The heap is broken into small, fixed-size blocks.
Each block has a unit size that is power of two to
ease translating a requested size into the
corresponding required number of units
The dynamic memory allocation function, malloc,
has an input parameter that specifies the size of
the allocation request in bytes
malloc allocates a larger block, which is made up of
one or more of the smaller, fixed-size blocks. The
size of this larger memory block is at least as
large as the requested size; it is the closest to the
multiple of the unit size.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 32
States of a Memory Allocation
States of a Memory Allocation
Map
Map
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 33
Memory Allocation Map with
Memory Allocation Map with
Possible Fragmentation
Possible Fragmentation
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 34
Problems with Memory
Problems with Memory
Compaction
Compaction
Is allowed if the tasks that own those memory
blocks reference the blocks using virtual
addresses
Time-consuming
The tasks that currently hold ownership of those
memory blocks are prevented from accessing the
contents of those memory locations
Almost never done in practice in embedded
designs
The free memory blocks are combined only if they
are immediate neighbors
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 35
Needs of an Efficient Memory
Needs of an Efficient Memory
Manager
Manager
An efficient memory manager needs to perform
the following chores quickly:
Determine if a free block that is large enough
exists to satisfy the allocation request.(malloc)
Update the internal management information
(malloc and free).
Determine if the just-freed block can be
combined with its neighboring free blocks to
form a larger piece. (free)
The structure of the allocation table is the key
to efficient memory management
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 36
An Example of
An Example of
malloc
malloc
and free
and free
Static array implementation of the
allocation map
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 37
Finding Free Blocks Quickly
Finding Free Blocks Quickly
Always allocates from the largest available
range of free blocks
The sizes of free blocks within the
allocation array are maintained using the
heap data structure
Each node in the heap contain the size of a
free range and its starting index in the
allocation array
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 38
Free Blocks in a Heap
Free Blocks in a Heap
Arrangement
Arrangement
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 39
The
The
malloc
malloc
Operation
Operation
Examine the heap to determine if a free block
that is large enough for the allocation request
exists.
If no such block exists, return an error to the
caller.
Retrieve the starting allocation-array index of the
free range from the top of the heap.
Update the allocation array
If the entire block is used to satisfy the
allocation, update the heap by deleting the largest
node. Otherwise update the size.
Rearrange the heap array
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 40
The
The
free
free
Operation
Operation
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 41
The
The
free
free
Operation
Operation
Update the allocation array and merge neighboring blocks if
possible.
If the newly freed block cannot be merged with any of its
neighbors, insert a new entry into the heap array.
If the newly freed block can be merged with one of its
neighbors, the heap entry representing the neighboring
block must be updated, and the updated entry rearranged
according to its new size.
If the newly freed block can be merged with both of its
neighbors, the heap entry representing one of the
neighboring blocks must be deleted from the heap, and the
heap entry representing the other neighboring block must be
updated and rearranged according to its new size.
YZUCSE SYSLAB
CS512 Embedded RTOS
Fixed
Fixed
-
-
Size Memory
Size Memory
Management in
Management in
Embedded Systems
Embedded Systems
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 43
Fixed
Fixed
-
-
Size Memory Management
Size Memory Management
in Embedded Systems
in Embedded Systems
Management based on memory pools
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 44
Fixed
Fixed
-
-
Size Memory Management
Size Memory Management
in Embedded Systems
in Embedded Systems
Advantages
more deterministic than the heap
method algorithm (constant time)
provide high utilization for static
embedded applications
Disadvantages
This issue results in increased internal
memory fragmentation per allocation for
embedded applications that constantly
operate in dynamic environments
YZUCSE SYSLAB
CS512 Embedded RTOS
Blocking vs. Non
Blocking vs. Non
-
-
Blocking
Blocking
Memory Functions
Memory Functions
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 46
Blocking vs. Non
Blocking vs. Non
-
-
Blocking
Blocking
Memory Functions
Memory Functions
If tasks know that the memory congestion
condition can occur but only momentarily,
and it can tolerate the allocation delay, the
tasks can choose to wait for memory to
become available instead of either failing
entirely or backtracking
In practice, a well-designed memory
allocation function should allow for
allocation that permits blocking forever,
blocking for a timeout period, or no
blocking at all.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 47
Implementing a Blocking Allocation
Implementing a Blocking Allocation
Function Using a
Function Using a
mutex
mutex
and a
and a
Counting Semaphore
Counting Semaphore
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 48
Blocking Allocation/
Blocking Allocation/
Deallocation
Deallocation
Pseudo code for memory allocation
Acquire(Counting_Semaphore)
Lock(mutex)
Retrieve the memory block from the pool
Unlock(mutex)
Pseudo code for memory deallocation
Lock(mutex)
Release the memory block back to into the pool
Unlock(mutex)
Release(Counting_Semaphore)
YZUCSE SYSLAB
CS512 Embedded RTOS
Memory Leak Detection
Memory Leak Detection
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 50
Memory Leak Detection
Memory Leak Detection

An error in a program's dynamic


An error in a program's dynamic
-
-
store
store
allocation logic that causes it to fail to
allocation logic that causes it to fail to
reclaim discarded memory, leading to
reclaim discarded memory, leading to
eventual collapse due to memory exhaustion
eventual collapse due to memory exhaustion

How to detect memory leak?


How to detect memory leak?

employ special debugging libraries to ensure


employ special debugging libraries to ensure
their correct behavior in term of memory use
their correct behavior in term of memory use

Mtrace
Mtrace
,
,
Electric Fence,
Electric Fence,
dmalloc
dmalloc
,
,
MEMWATCH
MEMWATCH

hardware tools
hardware tools

Logic analyzer, ICE


Logic analyzer, ICE
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 51
mtrace
mtrace

A feature of the GNU C library


A feature of the GNU C library

Implemented as a function call,


Implemented as a function call,
mtrace
mtrace
()
()

Detection of memory leaks caused by


Detection of memory leaks caused by
unbalanced
unbalanced
malloc
malloc
/free calls
/free calls

Creates a log file of addresses


Creates a log file of addresses
malloc'd
malloc'd
and freed
and freed
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 52
Electric Fence
Electric Fence
It is a library that replaces the C librarys
memory allocation functions, such as
malloc(), and free(), with equivalent
functions that implement limit testing
Very effective at detecting out-of-bounds
memory reference
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 53
dmalloc
dmalloc

A library
A library

Designed as a drop
Designed as a drop
-
-
in substitute for
in substitute for
malloc
malloc
,
,
realloc
realloc
,
,
calloc
calloc
, free
, free
and other memory
and other memory
management functions
management functions

Keep track debug information about your


Keep track debug information about your
pointer
pointer

Verify the debug information and logged


Verify the debug information and logged
on errors.
on errors.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS 54
References
References
Qing Li and Caroline Yao, Real-Time Concepts for Embedded
Systems, CMP Books, ISBN: 1-57820-124-1, 2003.
Anthony J. Massa, Embedded Software Development With
eCos, Prentice Hall, ISBN: 0-13-035473-2, 2003.
Michael Barr, Programming Embedded Systems in C and C
++, O'Reilly & Associates, January 1999.
Karim Yaghmour, Building Embedded Linux Systems,
O'Reilly & Associates, ISBN: 0-596-00222-X, 2003.
Jean J. Labrosse, "MicroC OS II: The Real Time Kernel,"
ISBN: 1578201039, CMP Books, June 15, 2002.
Silberschatz, Galvin, and Gagne, Operating System
Concepts, John Wiley, 2002.

You might also like