sof
sof copied to clipboard
[FEATURE][Zephyr] Add stack checks to component info
Is your feature request related to a problem? Please describe. Currently some components require stacks larger than the default, if you forget to modify the stack you are in for a bad time trying to figure out what you messed up
Describe the solution you'd like Zephyr provides us a better opportunity given its rich APIs. In theory we can actually check our current stack size to make sure we are compatible before we even run the component if the information is packaged with the component.
Describe alternatives you've considered N/A, Stack is based on FW currently but core assignment is in the topology, makes it very hard to validate outside of runtime
Additional context https://github.com/thesofproject/sof/pull/6746#pullrequestreview-1211882309
@marcinszkudlinski @juimonen I assume we can add stack sizes to rimage toml to build into the manifest ?
What about comp_driver_info
?
What about
comp_driver_info
?
I think we have a similar use case for Windows and trying to align the flow around Zephyr/IPC. @mwasko and @marcinszkudlinski working on configuration flow now.
Understood :)
What about
comp_driver_info
?I think we have a similar use case for Windows and trying to align the flow around Zephyr/IPC. @mwasko and @marcinszkudlinski working on configuration flow now.
@cujomalainey with the loadable libraries introduction we have a stack_size field defined and a plan is to use it for DP/EDF module Thread initialization.
Pencil this in for v2.5 at end of Q1/23
V2.5 branching this week and nobody assigned, so moving to v2.6.
Moved to v2.7 - Loadable modules in progress.
I've verified Zephyr CONFIG_STACK_SENTINEL=y with SOF and it's work as advertized. I left a mention of this to sof/app/debug_overlay.conf , so it's easier for SOF developer to find. This doesn't address the enhancement ticket as such, but this is one concrete tool to investigate suspected stack sizing issues.
FYI to @jxstelter and @pjdobrowolski working on loadable modules support.
@cujomalainey @lgirdwood @alex-cri I propose we move to v2.8. There is incremental work done that helps to address issues like https://github.com/thesofproject/sof/pull/6746/commits/104ed3e906ac1105060a5bc5487752cde80e61ba , including:
- Zephyr tooling to analyze stack usage (CONFIG_STACK_SENTINEL and CONFIG_STACK_USAGE)
- the new Data Processing module support (https://github.com/thesofproject/sof/pull/8020 and friends) design allows to read stack information from module manifest, and create a dedicated thread with appropriate size (i..e. stack is dimensioned to the module). for now stack is fixed to TASK_DP_STACK_SIZE
But e.g. for the more common low-latency modules, the stack size continues to be a global build time setting and we do not have infra in SOF for modules to declare the stack sizes, and to discover the maximum at build time and use this to size the LL-thread size. I believe this is at the root of the original ask @cujomalainey , right. The loadable modules further complicate this (a loaded LL-module will have to run in the same thread, so we cannot re-dimension the stack size of existing LL-threads).
@kv2019i , I agree with your takeaways. Will give a day for any further comments to come in then plan to move to v2.8.
Bumping to v2.9. If anyone has fresh examples and possible experiences using the Zephyr stack debug tools (and any shortcomings), please add here.