Min Heap Threshold Callback? "OOM Killer"?

p-rimes
Posts: 89
Joined: Thu Jun 08, 2017 6:20 pm

Min Heap Threshold Callback? "OOM Killer"?

Postby p-rimes » Sun Sep 30, 2018 11:33 pm

Hi there,

Wondering whether there is some feature in esp-idf to execute a (user-provided) callback when a low memory condition is reached?

Such that -- for example -- we can have application code that runs when heap reaches 10KB remaining, and in that case select a task and delete it (or make some attempt to reclaim memory other than rebooting, perhaps disabling some other features).

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: Min Heap Threshold Callback? "OOM Killer"?

Postby ESP_Angus » Mon Oct 01, 2018 5:10 am

No, there's no built-in feature. Suggest adding a timer callback with a regular free memory check and whatever response makes sense in that particular firmware.

One difficulty for an "OOM Killer" type approach, compared to Linux, is that ESP32 has no memory protection. Killing a task only frees that task's stack memory, and doesn't otherwise clean anything up (network resources, memory, FreeRTOS resources/lock state, etc).

p-rimes
Posts: 89
Joined: Thu Jun 08, 2017 6:20 pm

Re: Min Heap Threshold Callback? "OOM Killer"?

Postby p-rimes » Mon Oct 01, 2018 5:49 am

ESP_Angus wrote:No, there's no built-in feature. Suggest adding a timer callback with a regular free memory check and whatever response makes sense in that particular firmware.

One difficulty for an "OOM Killer" type approach, compared to Linux, is that ESP32 has no memory protection. Killing a task only frees that task's stack memory, and doesn't otherwise clean anything up (network resources, memory, FreeRTOS resources/lock state, etc).
That's pretty much what I have for now, a recurring timer using a combo of `heap_caps_get_per_task_info` and `uxTaskGetSnapshotAll` to determine heap/stack usage of each task. I do have a messaging layer (ringbufs) between tasks which can trigger a task to delete itself (which, through C++ RAII will free/release all the allocated resources).

However, my worry is that the timer approach won't be able to respond fast enough to react to a series of large allocations e.g. starting a TLS connection (the biggest typical offender in my apps). I suppose I was hoping for a feature that wrapped `malloc` or interacted with the heap tracking / heap-poisoning stuff, if this could be considered a feature request?

ESP_igrr
Posts: 2067
Joined: Tue Dec 01, 2015 8:37 am

Re: Min Heap Threshold Callback? "OOM Killer"?

Postby ESP_igrr » Mon Oct 01, 2018 6:27 am

trigger a task to delete itself (which, through C++ RAII will free/release all the allocated resources
Keep in mind that FreeRTOS vTaskDelete does no unwind stack frames, and does not cause destructors of local variables to be called.
You may, however, throw a C++ exception from the place where the task receives OOM message, and catch it in the task function, calling vTaskDelete afterwards.

p-rimes
Posts: 89
Joined: Thu Jun 08, 2017 6:20 pm

Re: Min Heap Threshold Callback? "OOM Killer"?

Postby p-rimes » Mon Oct 01, 2018 6:43 am

ESP_igrr wrote:
trigger a task to delete itself (which, through C++ RAII will free/release all the allocated resources
Keep in mind that FreeRTOS vTaskDelete does no unwind stack frames, and does not cause destructors of local variables to be called.
You may, however, throw a C++ exception from the place where the task receives OOM message, and catch it in the task function, calling vTaskDelete afterwards.
Good to know! I hope I'm catching your meaning, but this would only apply if I try to vTaskDelete a different task that is still in the middle of running? In my case the xTaskCreate/vTaskDelete happen within C++ constructors/destructors (the task function gets access to the 'this' pointer through userdata), and the instance is added to a static unordered_map (with all the other created tasks). So when erasing from the task map, vTaskDelete is always the last command that gets run within the destructor. Hope this is still alright, what would the implications be?

Who is online

Users browsing this forum: Google [Bot] and 140 guests