This feature keeps track of the per task peak memory usage.
- Update the heap_task_tracking example to make use of the new feature
Cleanup the implementation:
- multi_heap_get_free_size() is never used, remove it.
- Minor update in heap_caps_update_per_task_info_xx() funcitons.
- Update settting on block owner in heap_caps.c to work with the
get peak usage feature.
- Update heap_caps_update_per_task_info_free() to detect when it
is called to delete the memory allocated for a task TCB. Mark
the corresponding task in the statistic list as deleted.
- Add a Kconfig option dependant on HEAP_TASK_TRACKING being enabled
that force the deletion of the statistics related to deleted task
when set to true.
- In task tracking feature, add a current and peak memory usage
to the heap_stat_t structure to keep track of the current and
peak memory usage of the given task across all heaps.
- Fix missing block owner when allocating memory for heaps_array
in heap_caps_init.
- Keep the original implementation of the task tracking
for backward compatibility reasons.
For a given group of heaps sharing the same capabilities, it is
best to use smaller heaps first when performing "small" allocations
to keep the bigger heaps untouched. This prevents the scenario where
a series of small allocations would crowd the bigger heaps making
any bigger allocation fail for lack of space.
Closes https://github.com/espressif/esp-idf/issues/13588
don't check for heaps_array != NULL in the loop.
The check is done after the loop since it is allowed
for the allocation to fail until finding aa ssuitable
heap.
1. move startup_stack attr from soc_memory_type_desc_t to soc_memory_region_t and
remove unused aliased_iram field
2. all of the last level of RAM is retention dma accessible on esp32c3
3. remove esp32c2 and later chips retention dma accessible memory caps
4. allow allocate memory from RTC_RAM with MALLOC_CAP_EXEC cap
Previously, condition_4 was making impossible the valid scenario
start > heap_start && end == heap_end.
Now, the end == heap_end and start == heap_start case is handled
separately allowing the case start > heap_start && ned == heap_end
to be considered a valid scenario
Regression was introduced in 32408b718f, which disallowed
addition of heap region with following condition:
`new_start < start && new_end == start`
This caused issues in Bluetooth APIs `esp_bt_mem_release` or `esp_bt_controller_mem_release`.
This commit fixes the problem and also adds API documentation for supported memory address
ranges in heap add region APIs.
A memory region starts from REGION_START and ends at
(REGION_START+SIZE-1).
Prior to this change, the check assumes a to-be-added region starting from REGION_START is invalid. Let's take an easy example:
A memory region: 0x1000~0x10ff
new added region: 0x1000~0x1020
This will be valid.
Valid conditions and invalid conditions are illustrated in the code comment
Problem:
The new API esp_bt_mem_release() that was added freed BTDM data to heap from esp_bt_controller_mem_release().
Now with the BT memory optimization commit ee787085f9,
the BTDM data is optimized and reduced to only 32 bytes which is not sufficient amount to be added to heap.
So, using the API leads to assert saying that the region is too small.
Solution:
Modify heap_caps_add_region_with_caps to return ESP_ERR_INVALID_SIZE in case the range is too small to create a new heap.
Do not assert if return value is ESP_ERR_INVALID_SIZE
This also fixes using API esp_bt_controller_mem_release() with ESP_BT_MODE_BTDM
Signed-off-by: Hrishikesh Dhayagude <hrishi@espressif.com>
No longer necessary to keep all reserved addresses in 'soc'.
Means 'soc' does not need to know about 'bt', for example.
Also means that Bluetooth can be enabled in config without any memory being reserved for BT
controller. Only if code calling the BT controller is linked in, will this memory be reserved...
