-
Notifications
You must be signed in to change notification settings - Fork 17
WIP: user heap using shared multi heap on Zephyr #102
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
Conversation
the user_malloc and user_free functions will be used on platforms with support for external PSRAM. This way we can differentiate allocations in the internal or external RAM. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
These functions allocate memory on external PSRAM on boards that have CONFIG_SHARED_MULTI_HEAP enabled. Otherwise, they work just like core_malloc and core_free. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
On systems with a single heap, these functions work exactly the same as malloc and free. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The user heap is user for large objects. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Use the user heap for wamr and related container memory. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
In favor of the user heap mechanism. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
We now use the user heap mechanism. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
f1c6402 to
67f4de0
Compare
| memset(&init_args, 0, sizeof(RuntimeInitArgs)); | ||
| init_args.mem_alloc_type = Alloc_With_Pool; | ||
| init_args.mem_alloc_option.pool.heap_buf = wamr_heap_buf; | ||
| init_args.mem_alloc_option.pool.heap_size = sizeof(wamr_heap_buf); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we use system heap in systems where we don't have PSRAM for wasm, then we can't limit it anymore. I don't think it's good - we need a way to limit max amount of warm's linear memory, don't we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should enable WASM_MEM_ALLOC_WITH_USAGE and limit the amount of memory per-container instead. This is just the allocation. Every use of user_malloc should properly handle the ENOMEM error and recover gracefully if possible.
|
Discussion notes:
|
|
Closing this in favor of #116 |
Description
In embedded systems with external PSRAM, we usually want to store our objects in two different heaps: one system heap for small and fast objects (like the internal SRAM); and another user heap or application heap which is used for large objects stored in external slow PSRAM.
This adds the user heap interface in ocre, and sets WAMR to use it as the application heap. We also use it to store the container parameter as well as the container image executable for running in WAMR.
This ultimately removes the need for the two build time configuration variables and make them automatically use the external heap.
In MMU systems, we usually only have one heap, so
user_malloc()does the same ascore_malloc().TODO:
user_realloc()must be correclty implemented for Zephyr.Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration including the following required details.
Test Configuration (required):
pico_plus2Checklist: