mirror of
https://github.com/saymrwulf/xous-core.git
synced 2026-11-04 04:27:34 +00:00
A hard-OOM is what happens when the allocator really runs out of memory. To review, there are two types of OOMs handled by the swapper: - "OOM Doom": impending OOM. This is detected by a userspace process that can do more sophisticated processing and algorithms to predict an impending OOM. The OOM Doom handler is also interruptable, which allows other progresses to make progress while memory is being cleared up, hopefully allowing for a more graceful failure curve. - "Hard OOM": Literally no more pages are available. This is triggered when the page allocator can't map a single more page. The hard-OOM handler turns off all interrupts, and all the OOM process happens within the uninterruptable userspace context. This effectively turns the OOM handler "inside out" compared to the normal, interruptable userspace handler. In order to support this, a set of calls that implement the kernel space pre-amble and post-amble (i.e. StealPage and ReleaseMemory) are introduced. This does introduce an extra edge case in the exit path of the hard-OOM, namely, if the hard-OOM failed on a page that was swapped. Here, after clearing memory, we have an empty page, but no data; we have to again re-enter the userspace handler to fill that page. The twist here is we have to remember to re-instate interrupts on this edge case otherwise we lose pre-emption. |
||
|---|---|---|
| .. | ||
| arch | ||
| debug | ||
| platform | ||
| args.rs | ||
| io.rs | ||
| irq.rs | ||
| macros.rs | ||
| main.rs | ||
| mem.rs | ||
| server.rs | ||
| services.rs | ||
| swap.rs | ||
| syscall.rs | ||
| test.rs | ||
| utils.rs | ||