CS512 Embedded RTOS

Embedded RTOS Memory Management

C.-Z. Yang http://syslab.cse.yzu.edu.tw/~czyang

YZUCSE SYSLAB

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

Logical vs. Physical Address 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

Memory-Management Unit (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.
CS512 Embedded RTOS

YZUCSE SYSLAB czyang@acm.org

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 operatingsystem 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

Hardware Support for Relocation and Limit Registers

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

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

Multiple-partition allocation

OS process 5

OS process 5

OS process 5 process 9

OS process 5 process 9 process 10

process 8 process 2 process 2 process 2

process 2

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

Dynamic Storage-Allocation 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

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.
CS512 Embedded RTOS

YZUCSE SYSLAB czyang@acm.org

10

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

11

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

12

Address Translation Architecture

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

13

Paging Example

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

14

Free Frames

Before allocation
YZUCSE SYSLAB czyang@acm.org

After allocation
CS512 Embedded RTOS 15

Paging Hardware With TLB

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

16

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

17

Valid (v) or Invalid (i) Bit In A Page Table

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

18

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.
CS512 Embedded RTOS 19

YZUCSE SYSLAB czyang@acm.org

Shared Pages Example

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

20

CS512 Embedded RTOS

Memory Management in Embedded Systems

YZUCSE SYSLAB

Memory Management in 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

22

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

23

Common Memory Types in Embedded Systems

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

24

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

25

Working with Flash Memory (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 hardwarespecific layer of software is usually called the Flash driver.

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

26

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 czyang@acm.org

CS512 Embedded RTOS

27

CS512 Embedded RTOS

Dynamic Memory Allocation in Embedded Systems

YZUCSE SYSLAB

Dynamic Memory Allocation 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

29

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

30

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

31

States of a Memory Allocation Map

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

32

Memory Allocation Map with Possible Fragmentation

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

33

Problems with Memory 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

34

Needs of an Efficient Memory 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

35

An Example of malloc and free

Static array implementation of the allocation map

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

36

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

37

Free Blocks in a Heap Arrangement

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

38

The malloc 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

39

The free Operation

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

40

The free 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 czyang@acm.org

CS512 Embedded RTOS

41

CS512 Embedded RTOS

Fixed-Size Memory Management in Embedded Systems

YZUCSE SYSLAB

Fixed-Size Memory Management in Embedded Systems

Management based on memory pools

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

43

Fixed-Size Memory Management 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 czyang@acm.org

CS512 Embedded RTOS

44

CS512 Embedded RTOS

Blocking vs. Non-Blocking Memory Functions

YZUCSE SYSLAB

Blocking vs. Non-Blocking 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

46

Implementing a Blocking Allocation Function Using a mutex and a Counting Semaphore

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

47

Blocking Allocation/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 czyang@acm.org

CS512 Embedded RTOS

48

CS512 Embedded RTOS

Memory Leak Detection

YZUCSE SYSLAB

Memory Leak Detection

An error in a program's dynamic-store allocation logic that causes it to fail to reclaim discarded memory, leading to eventual collapse due to memory exhaustion How to detect memory leak?
employ special debugging libraries to ensure their correct behavior in term of memory use Mtrace, Electric Fence, dmalloc, MEMWATCH hardware tools Logic analyzer, ICE
CS512 Embedded RTOS

YZUCSE SYSLAB czyang@acm.org

50

mtrace
A feature of the GNU C library Implemented as a function call, mtrace() Detection of memory leaks caused by unbalanced malloc/free calls Creates a log file of addresses malloc'd and freed

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

51

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

52

dmalloc
A library Designed as a drop-in substitute for malloc, realloc, calloc, free and other memory management functions Keep track debug information about your pointer Verify the debug information and logged on errors.

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

53

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.

YZUCSE SYSLAB czyang@acm.org

CS512 Embedded RTOS

54