Add option to set the core affinity for the Timer Svc Task on SMP systems

sudeep-mohanty commented 1 year ago

Title

Make Timer Service Task core affinity configurable

Description

This PR introduces the configTIMER_SERVICE_TASK_CORE_AFFINITY config option which allows a user to set the core affinity of the Timer Service Task on SMP systems. The motivation to have this feature comes from requests such as this and this on the ESP-IDF repository. It would be nice if the FreeRTOS-Kernel can support this natively.

Test Steps

N.A

Checklist:

[x] I have tested my changes. No regression in existing tests.
[ ] I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

None

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

codecov[bot] commented 1 year ago

Codecov Report

All modified lines are covered by tests :white_check_mark:

Comparison is base (1b2b090) 93.66% compared to head (8c1a99a) 93.66%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #805 +/- ## ======================================= Coverage 93.66% 93.66% ======================================= Files 6 6 Lines 2526 2526 Branches 604 604 ======================================= Hits 2366 2366 Misses 107 107 Partials 53 53 ``` | [Flag](https://app.codecov.io/gh/FreeRTOS/FreeRTOS-Kernel/pull/805/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=FreeRTOS) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/FreeRTOS/FreeRTOS-Kernel/pull/805/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=FreeRTOS) | `93.66% <100.00%> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=FreeRTOS#carryforward-flags-in-the-pull-request-comment) to find out more. | [Files](https://app.codecov.io/gh/FreeRTOS/FreeRTOS-Kernel/pull/805?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=FreeRTOS) | Coverage Δ | | |---|---|---| | [timers.c](https://app.codecov.io/gh/FreeRTOS/FreeRTOS-Kernel/pull/805?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=FreeRTOS#diff-dGltZXJzLmM=) | `98.77% <100.00%> (ø)` | |

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

archigup commented 1 year ago

Hey, thanks for the PR!

Could the #if ( configNUMBER_OF_CORES == 1 ) be moved inwards to just around the task create functions? Seems the rest of the logic in the blocks are the same.

sudeep-mohanty commented 1 year ago

Thanks for the review @archigup. Updated as suggested.

chinglee-iot commented 1 year ago

@sudeep-mohanty Thank you for creating the feedback. The issue in your description indicates that timer task is pinned to core 0 and blocked by higher priority tasks on core 0. As a result, the application watchdog callback can not be called within timeout. The alternative solution also suggests that allowing tasks to run on any core could be a better solution, which is the current setting for timer task. Therefore, this should not be an issue in FreeRTOS SMP.

On the other hand, user can consider to create another task with core affinity to serve application specific requirement instead of changing the affinity of timer task cause it may have effect on software timer service.

sudeep-mohanty commented 1 year ago

Thanks for the feedback @chinglee-iot. The idea here is to give users the flexibility of either pinning the timer task to a core or letting it run unpinned. Ofcourse, all issues with a lower priority task getting blocked by a higher priority task remain even on an SMP system irrespective of the task's core affinity, so IMO this PR shouldn't cause change to how the timer task runs in practice. A counter argument could be to let the timer task run on a separate core uninterrupted for a potentially more responsive timer service which is not possible today.