Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
schedule: add Tasks With Budget scheduler type #9075
base: main
Are you sure you want to change the base?
schedule: add Tasks With Budget scheduler type #9075
Changes from all commits
3e03e02
86499e1
470c3bb
e532e56
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This adds a risk that if someone changes
CONFIG_NUM_COOP_PRIORITIES
we might forget to change this one. Can we at least add an assert somewhere? In fact maybe even you can use arithmetics here directly and put-NUM_COOP_PRIORITIES
? I'm not sure if this would work but at least I did find one example in SOFand one in Zephyr:
and an even more elaborate calculation in Zephyr:
So, maybe that would work! But at the very least we need asserts!
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.
I was trying to do it this way but it failed when I added minus sign to default value.
But based on your examples it should work so I will check again
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.
@abonislawski just want to confirm we still have a thread level with higher priority than LL ? i.e. in case we need some special task in the future that is needed to preempt LL
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.
@lgirdwood no, currently we have LL on -CONFIG_NUM_COOP_PRIORITIES so highest possible priority but we can easily change that
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.
NUM_PREEMPT_PRIORITIES
. Ah, found it: you can userange
here in Kconfig to limit these numbers, e.g.