-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core: make idle thread optional #14224
core: make idle thread optional #14224
Conversation
This breaks the schedstatistics module 😢 |
I would like to inverse the logic. Could we instead have a feature (and corresponding module) such as Providing a feature instead of disabling a module seems more natural to me. |
5804c65
to
64a7bbb
Compare
done |
This'll need reworking the sched_cb logic: |
core/sched.c
Outdated
@@ -80,11 +80,14 @@ int __attribute__((used)) sched_run(void) | |||
{ | |||
sched_context_switch_request = 0; | |||
|
|||
#ifndef MODULE_CORE_IDLE_THREAD | |||
while (!runqueue_bitcache) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note to self: as is, the compiler must assume that sched_arch_idle() calls a function that modifies runqueue_bitcache (it is static in this compilation unit). With LTO, it might come to a different result. need to make this atomic or volatile.
I marked this WIP, as there's some code that expects that there's always an active thread (e.g., most of the IPC code due to sched_switch()). |
this one needs a rebase now :) |
d73879e
to
f922e2b
Compare
It seems to me that all that code is actually called when within thread context, meaning that having no active thread won't happen. So I've removed WIP. |
34f0915
to
08d4d31
Compare
08d4d31
to
f85f782
Compare
Turns out the unittest hard fault was caused by too a too small stack for main. I've added a commit to increase it slightly. (stack is also small on master, depending on compiler, it hard faults there without increase. This was unnoticed as the crash happens after finishing the tests). |
This PR still needs two ACKs to be merged before soft feature freeze (which I will anounce in a few hours) ;-). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first ACK!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK!
And go! |
Thanks for reviewing! |
Now let's rethink making the |
With #14224 the idle thread became optional, so the main thread can have either 1 or 2 as PID, depending if the idle thread is included or not. As this might also change in the future, it is probably the best to just expect any number.
Bisecting I have 0ff9e55 causing
|
With RIOT-OS#14224 the idle thread became optional, so the main thread can have either 1 or 2 as PID, depending if the idle thread is included or not. As this might also change in the future, it is probably the best to just expect any number. (cherry picked from commit 5599b06)
With RIOT-OS#14224 the idle thread became optional, so the main thread can have either 1 or 2 as PID, depending if the idle thread is included or not. As this might also change in the future, it is probably the best to just expect any number. (cherry picked from commit 5599b06)
With RIOT-OS#14224 the idle thread became optional, so the main thread can have either 1 or 2 as PID, depending if the idle thread is included or not. As this might also change in the future, it is probably the best to just expect any number. (cherry picked from commit 5599b06)
Totally not related to #14557, some measurements on the same54-xpro with bench_mutex_pingpong:
|
Contribution description
This PR makes the idle thread optional, if the architecture implements support for that.
In order to do that, an architecture needs to implement
sched_arch_idle()
and disable the modulecore_idle_thread
.The main benefits are:
The PR includes an implementation for CortexM3 and higher (M0+ doesn't support dynamically changing IRQ priorities, which the current implementation relies on).
Testing procedure
Any threading application obviously still needs to work. Also, the pm machinery needs to work as before.
Any shell test should confirm that the scheduler is idling (not switching to any thread if there's no runnable) and reacting to ISR (react to uart input and re-schedule shell thread).
I tested power management using tests/periph_pm, confirming that unblocking the right mode for a while makes the shell unresponsive (power mode has been set), and that when the RTC interrupt triggers, shell works again.
edit the commit history looks a bit scary due to #13825 being included. The new logic of this PR is contained in the latest two commits (one for basic support in core, one for the cortexm implementation).
Issues/PRs references
This PR needs #13825, which re-writes the Cortex-M PendSV logic so it can handle the case where there's no thread to save on entry.