[Sirened]

I feel like the kernel live locking in low memory environments should be treated as a bug and not something we try to solve using swap. Like...if the OOM killer can't free memory under low memory constraints, something has gone seriously wrong

[nyanpasu64]

I've tried twice to update Lakka (a custom Linux image that runs RetroArch and emulators) on a RPi 3B with 1 gigabyte of memory (and I think no swap). Updating Lakka from the Pi itself invokes a script which downloads a file from the network to SD card storage. This should not take up unbounded amounts of memory, but seems to trigger OOM livelock or something anyway (I can't tell what it is, since the GUI and SSH session hang, and Lakka doesn't enable Alt+SysRq or TTYs for some godforsaken reason). Enabling SSH and running `watch -n1 free -h` shows a concerningly low free memory amount, and IIRC the available memory number crept downwards before the GUI and SSH session both hung simultaneously.

Terminating the GUI and performing an offline update from one SSH session while running `watch -n1 sync` avoids the hang. I haven't tried sync while leaving the GUI running.

Will Linux OOM handling ever be fixed?

[tsimionescu]

The problem is the OOM killer only runs if no pages can be freed. But, on any system, there is some amount of memory that can be swapped out: code pages can be swapped out to their executable/library files on disk. On a system only running a few processes, this is unlikely to matter.

But if you have a lot of processes, you may end up in a situation where you can free enough pages by swapping them all out to disk. Now you have no OOMKill, but the next time a process gets to run, you will stall until it is swapped in from disk. Then, the next process will be scheduled, and it too will need to be swapped in, causing another stall, and so on. The machine will probably end up executing, at best, a few instructions per millisecond for hours...