I am testing FreeRTOS performance on DSP core c7x.
I am creating a project that tests several FreeRTOS mechanisme like semaphore or mutex. 1 task is created for each tested mechanisme.
First created task is for semaphore with priority level 3. Binary and Counting were tested with and without context switch.
For the context switch, a task with the highest priority level was created and changes from blocked/running state thanks to a semaphore
Data performance were satisfying.
Then 2nd task was created to test mutexes with priority level 2 (executed after semaphore). All test on semaphore without context switch give same results but semaphore with context switch are twice slower after adding this task.
Even if I change the priority level to start by the mutex task then delete it or force it into blocked state, the semaphore with context switch are slower.
I also tried to use configOPTIMIZE_FOR_LATENCY inf the config file but it didn’t changed anythings
How can I fix this ? Does it came from the scheduler ?
First, I would say you are using code that didn’t come from the official FreeRTOS git repo, so we are not familiar with it’s implementation so can only provide general guidance.
All test on semaphore without context switch give same results but semaphore with context switch are twice slower after adding this task.
Prior to adding this task you measured a switch to a priority 3 task. Are you saying after adding the new priority 2 task the previous switch to the priority 3 task is also twice as long. Or that the switch to the priority 2 task takes twice as long as the switch to the priority 3 task.
I don’t know what this is, or what it does. Can you link to it in a git repo somewhere? It might be similar to our portUSE_PORT_OPTIMISED_TASK_SELECTION, which for other processors moves the code that selects the next task to run into the port layer so it can make use of architecture specific assembly instructions. For example, a count-leading-zeros instruction to use a single asm line to pick the highest priority from a bitmap stored in an integer.
I am using code from TI demo using FreeRTOS kernel and adapted for our architecture.
The context switch is measured only in the priority 3 task and it is always the same measurement. First task 3 create a high priority task. This high priority task is pending a non available semaphore and then enter in blocked state. A context switch occure and task 3 is running again, measure the time and then post the semaphore to unblock the high priority task. I am doing this several time in a while loop.
Then i add in the main code a priority 2 task. I compile the code, reset the board, etc. I restart all measurement and I notice that context switch time is twice slower.
Sorry, It is not a FreeRTOS defined config. configOPTIMIZE_FOR_LATENCY is a define that enable or disable assert, checking for stack overflow, generation for tun time stats. It should optimize task switching latency but that didn’t solved my issue.
Can you maybe post a snippet of your code here?
Just enough to help us understand what are the priorities and what are the tasks doing.
Because, looking at your explanation, it seems that priority(task2) < priority(task3) < priority(task4). Where task3 creates task4 which is waiting on the semaphore; and task2 is the new task that you added which is causing you to see twice the amount of time to context switch.
If that is the case, then task2 should never get to run as long as task3 and task4 are running.
Also, I can not find any hint as to what mechanism is used to measure context switch turnaround time. I am afraid that the TO will not be able to obtain useful hints without presenting their test suite code.
