API method to get available mempool

[markus-becker-tridonic-com]

Is your feature request related to a problem? Please describe. At design time for a product, you want to be able to verify that the heap/mempool usage is bounded.

Describe the solution you'd like An API method like size_t sys_mem_pool_avail().

mbedOS is offering mbed_stats_heap_get(): https://os.mbed.com/docs/mbed-os/v5.15/tutorials/optimizing.html

[carlescufi]

@andyross any comments on this?

[andyross]

Heh, I knew I'd seen this. Should have just checked my assigned bugs.

This isn't hard for the simple case of "memory available". The sys_heap implementation is a contiguous array of "chunks" of fixed size. We know how many there are in total trivially, one extra word of storage and ~3 instructions per operation would allow us to track the number unallocated. Then the API would look something like:

u32_t sys_heap_max_chunks(struct sys_heap *h);
u32_t sys_heap_free_chunks(struct sys_heap *h);

Or we could return a "stats" struct like mbed does with both fields included.

As for the other stuff in mbed... nothing looks difficult, but I question the utility of some of those fields ("Cumulative sum of bytes ever allocated." ... why?!).

[markus-becker-tridonic-com]

@andyross The base functionality of free and max heap would be fine.

[RobMeades]

I've been looking all over for this function in Zephyr, some kind person [@markus-becker-tridonic-com it would appear] just pointed this issue out to me on the mailing list.

I would question the "low priority": would you drive a car without a fuel gauge? We need this in our CI tests to check for memory leaks.

We tests our code on five different embedded platforms and Zephyr is the only one so far that doesn't offer a measure of heap usage. Could the priority be raised please?

[jukkar]

Or we could return a "stats" struct like mbed does with both fields included.

This might be better solution than having multiple functions. New fields could be added to such statistics struct more easily. We use similar stats structs in network statistics.

[bjda]

I needed this myself and made a draft at https://github.com/zephyrproject-rtos/zephyr/pull/29735 . It still presumably needs some work for better configuration, as well as some way to make it accesible for the main heap used by k_malloc, but feel free to try it out. For now it will printk() the stats after any alloc on any heap.

[RobMeades]

FYI, since newlib is being used by Zephyr under the hood (at least on my platform, NRF53) it is almost possible to do this by calling the newlib mallinfo() function. The reason this is only "almost" is that mallinfo() is not the whole story: newlib calls sbrk() as required to give it heap memory from the ultimate heap, so the real number is mallinfo's fordblks plus what's left in sbrk(): without this the reported heap can end up going UP from it's original value, a "negative leak", which would cause any strict heap checking to fail.

Unfortunately, the variable that tracks the memory left inside sbrk(), heap_sz in lib/libc/newlib/libc-hooks.c is static so one can't get at it to do the free heap calculation properly.

Hence the simplest change would be to remove the static from that variable, then people can solve the problem themselves.

[farhangj]

Any movement on this? It's fairly basic and necessary to know how much heap is available. Needs to be bumped up in priority IMO.

[dakejahl]

Bump

[zephyrbot]

Hi @andyross, @peter-mitsis,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@markus-becker-tridonic-com you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!

[andyross]

There's a heap statistics API now, closing

[d3zd3z]

I think this should be re-opened. There is a heap statistics API, but the now-in-common z_malloc_heap is a static, so there is no way to access it to use the heap statistics API. See #79123 as a simple solution to that.