Analysis of stack size for Active components

[sobkulir]

We are planning to use F' on a resource-constrained platform (~500KB RAM) and I was wondering if there's been any effort put into analyzing the maximum stack depth for each active component. From the Sphinx reference deployment it seems that the given stack size is not determined by any tool, but overshooted to not have to worry.

There're useful gcc flags for determining stack usage, like -fcallgraph-info=su and -fstack-usage (source). This works well with static function calls, for dynamic ones, like in the case of sync port calls, the topology information would need to be used. Additionally, components like (De)framer take the protocol implementation dynamically. However, all of these are determined at setup time so such analysis could be done in theory. WDYT? Do you see other blockers?

[LeStarch]

@ethancheez any thoughts here?

[ethancheez]

I was able to successfully run an F' deployment on hardware with 256KB FLASH and 32KB RAM. Out of that, F' only used ~140KB FLASH and ~25KB RAM. So I believe running on hardware with ~500KB RAM is possible.

I can provide input about the static memory allocation (bss) on setup time. When uploading an F' deployment, most of the data is stored in FLASH memory and is read-only. Static memory allocations (i.e. vectors created during setup time) will be written to RAM. The compiler you are using may come with a few size detecting tools that allow you to determine exactly how much data is written to FLASH and RAM. We based this off of the .bss model, where the .text and .data fields represents FLASH memory size and .bss is RAM. Unfortunately the stack size cannot be determined using these compiler tools as they are determined on runtime.

The compiler should have the size and nm tools that are part of their package which allow you to determine the text, data, and bss sizes.

1. The size tool shows you the size of the full binary executable so you know how much memory your F' deployment needs.
2. The nm tool is capable of showing you the bss sizes of each F' component in your topology (how much static memory was allocated within that specific component on setup time). I used the -CStd flag when running the nm tool.

If you combine these tools along with using the SystemResources F' component, you can estimate how much dynamic memory is being allocated.

[sobkulir]

Maybe mentioning the total RAM we have was a bit misleading. We are already using tools for showing FLASH/RAM utilization of the binary (Zephyr shows this info automatically for every build). However, this information is not useful for deciding on the right amount of stack memory.

The dynamic solution for this is watermarking every stack and dynamically checking if a certain watermark has been reached. Though there might still be a call path not exercised during testing which goes above the watermark and potentially overflows the stack during deployment. Contrary to this, the static analysis would account for the worst case.

I believe it would be very useful and interesting to look into the static analysis so I wanted to see if there's already been an effort on this front :)

[LeStarch]

When asking about "resource constrained systems" we jumped to the assumption of a baremetal deployment (no OS). Here per-component stack size is irrelevant as there are no "real" threads and there is only one stack. The patterns above work reasonably well to sizing within such systems.

The real question here is how to size stack size settings for system that have smaller RAM allocations in a system where the per-thread (and thus per-active component) have real meaning (i.e. an Os environment with a proper thread scheduler). This one may take more time to think through. As you said, there are dynamic invocations that aren't easily analyzed in a static analysis context and dynamic testing doesn't guarantee every path is taken. We've also seen that seemingly benign system-calls can allocate huge allocations on the stack for certain OSes.

I'll take some time to think through this, and see what I can come up with. Perhaps @timcanham might also have some insight.

[sobkulir]

I see, yes, from skimming through the Baremetal scheduler, it's indeed much simpler. The question then is if that one stack can't overflow, but the analysis would be basically the same as for the general case with many "real" threads. Although truth be told I'm not sure how the Baremetal scheduler works with Active components because the Baremetal Queue asserts that there's at least one element on blocking receive. While ActiveComponent::doDispatch() seems to call this blocking receive. So in theory the assert should fail as soon as there's nothing to dispatch.

Anyways, for our use case, we want to use "real" threads with priorities. I'm looking forward to your take on this, thanks for taking time to respond!

[timcanham]

It's not uncommon for embedded operating systems to have utilities for tracking stack usage on a per-thread basis. VxWorks has one. Sometimes it's a configuration option in the OS build, and then you can use vendor tools to check it. Here you talked about Zephyr requiring a pointer to stack space. Could you prefill that memory with a pattern, store the pointer somewhere and occasionally check it to see how far the pattern has been overwritten?

[sobkulir]

Yes, there's built-in support for this in Zephyr under the name Thread Analyzer. Here's an output from it from our app, it's very handy:

However, having a number from static analysis would mean that we would be able to make the bounds tighter without increasing risk.