S32K358 - freeRTOS SMP scheduling latencies

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K358 - freeRTOS SMP scheduling latencies

Jump to solution
1,884 Views

Hello NXP Team,

I am evaluating the use of FreeRTOS SMP for my project and would like to clarify a few technical aspects before proceeding.

As an example, 
Suppose we create 15 tasks using xTaskCreate(), with 12 tasks pinned to Core 0 and 3 tasks pinned to Core 2 (on S32K358) using vTaskCoreAffinitySet().

Based on this setup, I have the following questions:

  1. When using vTaskCoreAffinitySet() with explicit core masks, can we assume that tasks will run only on the specified cores and will not migrate to others?

  2. Since FreeRTOS SMP uses a single scheduler, could there be any scheduling latency, even for tasks that are explicitly pinned to specific cores?

  3. If such latency is possible, is there any way to detect or mitigate it?

  4. In SMP mode, how are hardware interrupts handled? For instance, if I want specific interrupts (e.g., GMAC) to be handled only by Core 2 (M7_2), how should this be configured? Any examples or guidance would be appreciated.

Best regards,
Sathish.

0 Kudos
Reply
1 Solution
1,831 Views
lequana2
NXP Employee
NXP Employee

Hi @sathishkumar_sunmugavel, please see my answers below for S32K368 FreeRTOS SMP.

1. Yes. The affinity is used to pin the task to the core. However, it is bitwise and user can pin one task to be scheduled on several cores. That means you can set several task to both Core 0 and Core 2.

2. Yes. There should be latency for scheduler because It is natural of FreeRTOS SMP works. The scheduler is managed by one MASTER core and this MASTER core is sharing resource with other. In some cases, this MASTER core can be blocked by other. And even worse, the priority for scheduler is set to lowest (following FreeRTOS User Guide) to prioritize the real-time IRQ/task.

lequana2_1-1750933135730.pnglequana2_1-1750933135730.png

 


3. The latency can be measured as it is the for loop inside FreeRTOS mechanism (task.c file). It is possible to either detect/mitigate by making minor changes inside FreeRTOS kernel. FreeRTOS is open-source, user can freely modify. However, it is out-of-scope for NXP FreeRTOS team. Because we need to deliver exactly what FreeRTOS in github.

4. The HW interrupt is also out-of-scope for FreeRTOS kernel. FreeRTOS kernel only manipulate the task but not responsible to register the IRQ handler (it is done via Real-time Driver APIs). And of course, if you want to pin the handler to specific core, you can register the IRQ in that specific core only you can register the IRQ in main.c, and have the #if to check the coreID before assign the IRQ handler.

View solution in original post

0 Kudos
Reply
3 Replies
1,832 Views
lequana2
NXP Employee
NXP Employee

Hi @sathishkumar_sunmugavel, please see my answers below for S32K368 FreeRTOS SMP.

1. Yes. The affinity is used to pin the task to the core. However, it is bitwise and user can pin one task to be scheduled on several cores. That means you can set several task to both Core 0 and Core 2.

2. Yes. There should be latency for scheduler because It is natural of FreeRTOS SMP works. The scheduler is managed by one MASTER core and this MASTER core is sharing resource with other. In some cases, this MASTER core can be blocked by other. And even worse, the priority for scheduler is set to lowest (following FreeRTOS User Guide) to prioritize the real-time IRQ/task.

lequana2_1-1750933135730.pnglequana2_1-1750933135730.png

 


3. The latency can be measured as it is the for loop inside FreeRTOS mechanism (task.c file). It is possible to either detect/mitigate by making minor changes inside FreeRTOS kernel. FreeRTOS is open-source, user can freely modify. However, it is out-of-scope for NXP FreeRTOS team. Because we need to deliver exactly what FreeRTOS in github.

4. The HW interrupt is also out-of-scope for FreeRTOS kernel. FreeRTOS kernel only manipulate the task but not responsible to register the IRQ handler (it is done via Real-time Driver APIs). And of course, if you want to pin the handler to specific core, you can register the IRQ in that specific core only you can register the IRQ in main.c, and have the #if to check the coreID before assign the IRQ handler.

0 Kudos
Reply
1,808 Views
lequana2
NXP Employee
NXP Employee

Hi @sathishkumar_sunmugavel any feedback on my answer ? Otherwise I shall close the topic today. Of course we can still discuss afterward.

0 Kudos
Reply
1,802 Views

Hi @lequana2 

Apologize for the late reply.

I got the required information from your response. So yes, we can close the topic. 

Thank you so much for your valuable input.

Best Regards,
Sathish.