Memory pools and allocation strategy

Kernel
1

Hi,
I’m missing support for memory pool with different properties, like On-Chip memory, cashed external, non-cached external.
Did not find anything better than modify heap_4 and then tasks.c in order to be able to allocate TCB and Stack from different pools.

Is there better solution envisioned?
For example, dynamic tasks but with user supplied stack, tcb, which is allocated by user from specific pool and freed to that pool by pvFree.
Thanks
Rasty

2

Hi Rasty,

FreeRTOS doesn’t support multiple memory pools feature yet. We can consider to use static memory APIs to use memory allocated from different memory pools. Use the following code as an example:

/* Allocate stack and TCB with different memory pool allocator of your own implementation. */
pxStack = pvMemoryPoolAllocate( ... );
pxTaskBuffer = pvMemoryPoolAllocate( ... );

xHandle = xTaskCreateStatic(
              vTaskCode,
              "NAME",
              STACK_SIZE,
              NULL,
              tskIDLE_PRIORITY,
              pxStack,
              pxTaskBuffer );

/* Free stack and TCB to the memory pool. */
vMemoryPoolFree( pxStack );
vMemoryPoolFree( pxTaskBuffe );

In this example, you will have to provide your own memory pool allocator.

3

It would be great if you could consider support of memory pools and finer control on memory allocation. Especially when it deals with memory consuming ofjects like tasks stacks.

4

The first versions of FreeRTOS only supported pools, but support was removed because users found it too complicated, and it wasted RAM back when there wasn’t much RAM available. At the time it was decided to instead keep memory allocation in the port layer so users could either use one of the memory allocators shipped with FreeRTOS, or define their own.

If you want to put the stack in fast RAM then use vPortMallocStack().

5

i try to fit software written for cortexA to cortexR.
major constrain is on-chip RAM.
dcache miss hurts. alot.
system written in cpp, i can overload new and put data where i want. good.
first step was wrapping heap-4 and allow multiply heaps, redirect vportAlloc to internal RAM. good.
then use static tasks with manually allocated stack for low latency tasks. good.
then figured out than i need dynamic tasks of both types - low latency with stack and tcb in low latency memory and service tasks with stack no matter where. problem.
things start to complicate.
it would be greate if i could pass an allocator/heap to taskcreate.

6

You should still be able to use static task creation APIs for creating both the types of tasks, right?

7

Right but in fact I need low latency non-static tasks.
I plan to do following

  1. Extend heap_4 to work with multiply heaps
  2. Add heap id/reference to heap control stucture (for Free function)
    I’m going to extend vTaskCreate and pass heap reference as optional parameter. It will allocate memory from specific heap, free() will return memory to the correct heap.
8

Why do those tasks need to be non static? The very idea of the concept IS to allow you to place the stack in a dedicated memory area.

9

That seems way more work and complexity as compared to just using static task creation.

10

Just Static task is not sufficient. Because I need 2 types memory allocation inside freeRTOS system calls.
“Fast memory” for small objects, like semaphores, tcb and stacks for low-latency tasks
“Slow memory” for big stacks of utility tasks that started/deleted at run-time.

11

We need to be careful about wording here. “Static” (not good terminology, I agree) in the sense of xCreateTaskSTATIC simply means that the caller provides the stack space. That does not have anything to do at all at what time you create your tasks. You can use either xCreateTask or xCreateTaskStatic for startup- or runtime managed tasks.

Btw, as we point out only about twice a week here, dynamically creating and deleting tasks at run time is in almost all cases a bad system design that you may want to revise. It is very error prone, inefficient and contradicts the philosophy of RTOS.

12

modern MPUs allow us to take existing design from big linux-style/vxWorks systems and push them to “embedded” nearly “as is”
Example is TCP/IP server threads (console style) that come and go. It works very well for serving HMI.
Static task cannot be deleted as far as I understand.

13

That is not correct.

14

We don’t use FreeRTOS memory allocation at all. Instead we use xCreateTaskStatic and similarly the static version of the Mutex creation function. Depending on whether the task is always needed or only sometimes, we allocate either static or dynamic memory for it.