Zephyr: API method to get available mempool

Created on 25 Feb 2020  路  7Comments  路  Source: zephyrproject-rtos/zephyr

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

Enhancement Kernel low

Most helpful comment

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?

All 7 comments

@andyross any comments on this?

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?!).

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

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?

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.

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.

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.

Was this page helpful?
0 / 5 - 0 ratings