Skip to content

Account for passive idle tasks in prvGetExpectedIdleTime for SMP - #1524

Open
gneverov wants to merge 1 commit into
FreeRTOS:mainfrom
gneverov:smp-tickless-expected-idle-time
Open

gneverov wants to merge 1 commit into
FreeRTOS:mainfrom
gneverov:smp-tickless-expected-idle-time

Conversation

@gneverov

Copy link
Copy Markdown

In SMP builds, each core has an idle task at tskIDLE_PRIORITY (one real, the rest passive), so the ready list at that priority always holds at least configNUMBER_OF_CORES tasks. prvIdleTask (tasks.c line 5868) and prvPassiveIdleTask (line 5958) already account for this by checking whether the length of that list is greater than configNUMBER_OF_CORES, but the same check in prvGetExpectedIdleTime (line 4038) was missed and still compares against 1. With more than one core, it always concludes that other idle priority tasks are ready and returns 0, so tickless idle never suppresses ticks. Apply the same comparison there. Single core behaviour is unchanged.

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

In SMP builds, each core has an idle task at tskIDLE_PRIORITY (one real, the rest passive), so the ready list at that priority always holds at least configNUMBER_OF_CORES tasks. prvIdleTask (tasks.c line 5868) and prvPassiveIdleTask (line 5958) already account for this by checking whether the length of that list is greater than configNUMBER_OF_CORES, but the same check in prvGetExpectedIdleTime (line 4038) was missed and still compares against 1. With more than one core, it always concludes that other idle priority tasks are ready and returns 0, so tickless idle never suppresses ticks. Apply the same comparison there. Single core behaviour is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant