currently in FreeRTOS idle threads created without affinity
that means it not possible to get idle percentage of specific core in SMP system via vTaskGetRunTimeStatistics. all IDLE threads will have almost same % time
also vApplicationIdleHook may be called from any cpu core, that may create unexpected conditions.
We can fix it by just setting affinity to each IDLE thread:
replace xTaskCreateStatic / xTaskCreate with xTaskCreateStaticAffinitySet / xTaskCreateAffinitySet when create idle thread
why FreeRTOS idle threads creates without affinity?
may i create PR with this change?
It is intentional to ensure that if core0 happens to be busy, the active idle task still gets chance to do house-keeping. Should you not be looking for overall system IDLE time instead of per core IDLE time?
Do you mean that active idle task calls prvCheckTasksWaitingTermination?
In this case user should load secondary cores, but keep some resources free in primary core
It can be useful to see per core IDLE time in case when some tasks pinned to specific core.
For example not all systems has fully SMP architecture. some peripherial can be accessed from one core fast, but from other core slow.
Some systems may have its own L1 cache for each core and pin computation tasks to specific core may increase perfomance because no need to reload data/code between L1 caches
Maybe we can add some config to kernel?
For example configIDLE_AFFINITY
I would think that with only some tasks pinned to cores, the individual core usage wouldn’t be that useful, as it will be highly affected by how the unpinned tasks hit the various cores. Perhaps the better measure (though would take a bit of effort to compute) would be the usage, by core, of task that were pinned to that core.
And, as for the efficacy of the per core level-1 cache, That might say that the scheduler might be better if it tried to reuse the core the task was last in, it will get much more progress running in a new core rather than not-running because some other higher priority task has the core it was last in. Note that if a task is interrupted by a higher priority task, which does just a bit of work and then blocks, the interrupted task will likely return to the core it started in, as that is the core the higher priority task just made free.