Memory Management
Unlike desktop virtual memory systems, vxWorks does not support page swapping and the amount of memory available to the vxWorks system (kernel and applications) is dependant on the hardware. The top address of the memory is returned in BSP function sysMemTop(). In many modern boards (particularly Motorola COTS boards), the value returned in sysMemTop() is determined dynamically by code in the BSP directory. In some cases, the BSP creator hardcodes the value.
The embedded system designer should become familar how sysMemTop() is determined. For example, if a hardcoded value for sysMemTop() is used and more memory is added to the board, vxWorks will not be aware of that memory and will not use it. Conversly systems designers often want large chunks of memory not controlled by the operating system. Hardcoding sysMemTop() to return a address somewhat below the real top of memory provides a conveniant method of getting a chunk of non-os aware memory.
CAUTION Some processors, particularly those that have Memory Management Units (MMUs), often share macros that define the accessibility of memory with sysMemTop(). The accessibility of memory is defined in the physical memory descriptor, sysPhysMemDesc or other mechanisms, such as powerPC BAT registers. Do not confuse os-awareness with processor accessiblity and tweak those macros with care.
When the vxWorks kernel is loaded into memory (or at least the data portions in the case of rom resident images), the loading starts at some point in low memory and uses contiguous memory up to the end of the kernel (&end). That portion of memory between the end of the kernel (&end) and sysMemTop() becomes the heap and is placed in the system memory partition.
The heap is then utilized by vxWorks and the application programs through the traditional memory allocation and release mechanisms, malloc() free(), new, delete etc.
In vxWorks 5.x, the heap manipulation is performed on the system memory partition using the routines defined in memLib. The malloc() and free() functions in vxWorks are wrappers that map directly to memPartAlignAlloc() and memPartFree().
The routines in memLib can also be used to add memory to the system memory partition. In some cases this memory is mapped in and physically resides on the pci or VME busses. The function memAddToPool() will allow the embedded system designer to treat offboard memory as system memory. This function is sometimes used to add memory that was reserved by moving down sysMemTop() back into the system memory partition. The partition id used to designate the system memory pool is defined in global variable sysMemPartId (?)
Heap management in vxWorks can present challenges to the embedded system designer. It must be remembered that the vxWorks memory model is flat, does not make use of virtual to physical mapping and is limited to the amount of physical memory available.
The heap manager is extremely simple and uses a “first fit” algorithm when walking the heap during a memory allocation cycle. That is, the first available block of memory of adequate size is split, if necessary, and returned to the user. While the deallocation routines will attempt to coalesce adjacent blocks, the heap can quickly become fragmented to the point that the heap manager is unable to complete a memory allocation request. This can also affect timing in that an allocation from a fragmented heap will take considerably longer complete than a memory allocation request from an unfragmented heap.
As a general guideline, while developing code for vxWorks 5.x, it is desirable to limit the amount of memory allocation and deallocation that occurs during the running of the program. If possible, all of the allocations should be done in the startup of the individual tasks. If not possible and a task is causing fragmentation, one possible cure is to use a separate memory partition for the fragmenting task.
The following code show how to create a separate memory partition and to overload malloc() and free()
Insert Code Excerpt Here
Once the separate memory partition is created, malloc() and free() can be overloaded with call to the memLib routines. The fragmentation, though not eliminated, is limited to the memory partition.
-- JohnGordon - 15 Apr 2003
-- JeraldPendleton - 19 May 2003
|
