Skip to content
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

API method to get available mempool #23076

Open
markus-becker-tridonic-com opened this issue Feb 25, 2020 · 12 comments
Open

API method to get available mempool #23076

markus-becker-tridonic-com opened this issue Feb 25, 2020 · 12 comments
Assignees
Labels
area: Kernel Enhancement Changes/Updates/Additions to existing features priority: low Low impact/importance bug

Comments

@markus-becker-tridonic-com
Copy link
Contributor

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

@markus-becker-tridonic-com markus-becker-tridonic-com added the Feature Request A request for a new feature label Feb 25, 2020
@carlescufi carlescufi added Enhancement Changes/Updates/Additions to existing features and removed Feature Request A request for a new feature labels Apr 7, 2020
@carlescufi
Copy link
Member

@andyross any comments on this?

@andyross
Copy link
Contributor

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
Copy link
Contributor Author

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

@nashif nashif added the priority: low Low impact/importance bug label Aug 13, 2020
@RobMeades
Copy link

RobMeades commented Oct 28, 2020

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
Copy link
Member

jukkar commented Oct 29, 2020

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
Copy link
Contributor

bjda commented Nov 3, 2020

I needed this myself and made a draft at #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
Copy link

RobMeades commented Nov 19, 2020

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
Copy link

farhangj commented Mar 2, 2021

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
Copy link

dakejahl commented Jun 8, 2021

Bump

@zephyrbot
Copy link
Collaborator

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
Copy link
Contributor

andyross commented Feb 9, 2024

There's a heap statistics API now, closing

@d3zd3z
Copy link
Collaborator

d3zd3z commented Sep 27, 2024

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.

@d3zd3z d3zd3z reopened this Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Kernel Enhancement Changes/Updates/Additions to existing features priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests