OS Abstractor always prefers to use the OS defrag methods for pools created using OS_Create_Memory_Pool API. Under VxWorks, the pool management and defrag is handled by the OS itself. Under Linux, we have two options: Option 1: This is a preferred option if the pool is big and varied size allocation. OS Abstractor does partial memory management but relies on the MMU assisted defrag and block allocation mechanism offered by the OS. Memory is not pre-allocated during pool creation but instead allocated at the time of request. OS Abstractor ensures that the applications do not over allocate system memory beyond what they are allowed (via OS_Application_Init API init call) for when they are created. As such failure of a memory request is unlikely even though allocations are done at request time. The disadvantage is that, there may be a non-OS Abstractor based application running along with OS Abstractor based applications eating up all the memory suddenly, which then could impact the OS Abstractor applications. Option 2: This is an option offered by MapuSoft for a smaller size pool in lieu of the above. Here the memory allocation is based on first fit. Automatic and limited defrag happens during each time the memory is freed. With every memory free request, the block adjacent to the freed block is checked and if free, then it gets combined into one bigger block. This defrag mechanism is no way close to how things are done via Option 1 (this is a custom request from MapuSoft).