Embedded RTOS Memory Management

Transcription

1 CS512 Embedded RTOS Embedded RTOS Memory Management C.-Z. Yang

2 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) czyang@acm.org CS512 Embedded RTOS 2

3 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. czyang@acm.org CS512 Embedded RTOS 3

4 Memory-Management 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. czyang@acm.org CS512 Embedded RTOS 4

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

6 Hardware Support for Relocation and Limit Registers CS512 Embedded RTOS 6

7 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) czyang@acm.org CS512 Embedded RTOS 7

8 Multiple-partition partition allocation OS OS OS OS process 5 process 5 process 5 process 5 process 9 process 9 process 8 process 10 process 2 process 2 process 2 process 2 czyang@acm.org CS512 Embedded RTOS 8

9 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. czyang@acm.org CS512 Embedded RTOS 9

10 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. czyang@acm.org CS512 Embedded RTOS 10

11 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. czyang@acm.org CS512 Embedded RTOS 11

12 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. czyang@acm.org CS512 Embedded RTOS 12

13 Address Translation Architecture CS512 Embedded RTOS 13

14 Paging Example CS512 Embedded RTOS 14

15 Free Frames Before allocation After allocation CS512 Embedded RTOS 15

16 Paging Hardware With TLB CS512 Embedded RTOS 16

17 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. czyang@acm.org CS512 Embedded RTOS 17

18 Valid (v) or Invalid (i) Bit In A Page Table czyang@acm.org CS512 Embedded RTOS 18

19 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. czyang@acm.org CS512 Embedded RTOS 19

20 Shared Pages Example CS512 Embedded RTOS 20

21 CS512 Embedded RTOS Memory Management in Embedded Systems

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

23 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 czyang@acm.org CS512 Embedded RTOS 23

24 Common Memory Types in Embedded Systems CS512 Embedded RTOS 24

25 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. czyang@acm.org CS512 Embedded RTOS 25

26 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. czyang@acm.org CS512 Embedded RTOS 26

27 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. czyang@acm.org CS512 Embedded RTOS 27

28 CS512 Embedded RTOS Dynamic Memory Allocation in Embedded Systems

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

30 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 czyang@acm.org CS512 Embedded RTOS 30

31 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. czyang@acm.org CS512 Embedded RTOS 31

32 States of a Memory Allocation Map czyang@acm.org CS512 Embedded RTOS 32

33 Memory Allocation Map with Possible Fragmentation CS512 Embedded RTOS 33

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

35 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 czyang@acm.org CS512 Embedded RTOS 35

36 An Example of malloc and free Static array implementation of the allocation map CS512 Embedded RTOS 36

37 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 czyang@acm.org CS512 Embedded RTOS 37

38 Free Blocks in a Heap Arrangement czyang@acm.org CS512 Embedded RTOS 38

39 The malloc 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 czyang@acm.org CS512 Embedded RTOS 39

40 The free free Operation CS512 Embedded RTOS 40

41 The free 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. czyang@acm.org CS512 Embedded RTOS 41

42 CS512 Embedded RTOS Fixed-Size Memory Management in Embedded Systems

43 Fixed-Size Memory Management in Embedded Systems Management based on memory pools CS512 Embedded RTOS 43

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

45 CS512 Embedded RTOS Blocking vs. Non-Blocking Memory Functions

46 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. czyang@acm.org CS512 Embedded RTOS 46

47 Implementing a Blocking Allocation Function Using a mutex and a Counting Semaphore czyang@acm.org CS512 Embedded RTOS 47

48 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) CS512 Embedded RTOS 48

49 CS512 Embedded RTOS Memory Leak Detection

50 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 czyang@acm.org CS512 Embedded RTOS 50

51 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 czyang@acm.org CS512 Embedded RTOS 51

52 Electric Fence It is a library that replaces the C library s memory allocation functions, such as malloc(), and free(), with equivalent functions that implement limit testing Very effective at detecting out-of-bounds memory reference czyang@acm.org CS512 Embedded RTOS 52

53 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. czyang@acm.org CS512 Embedded RTOS 53

54 References Qing Li and Caroline Yao, Real-Time Concepts for Embedded Systems, CMP Books, ISBN: , Anthony J. Massa, Embedded Software Development With ecos, Prentice Hall, ISBN: , Michael Barr, Programming Embedded Systems in C and C ++, O'Reilly & Associates, January Karim Yaghmour, Building Embedded Linux Systems, O'Reilly & Associates, ISBN: X, Jean J. Labrosse, "MicroC OS II: The Real Time Kernel," ISBN: , CMP Books, June 15, Silberschatz, Galvin, and Gagne, Operating System Concepts, John Wiley, czyang@acm.org CS512 Embedded RTOS 54