Post #1546492
2026-04-14 04:53 UTC
Replies (4)
-
@mokomull@macaw.social 2026-04-14 04:59
@regehr definitely doable with some cgroup management; setting `memory.oom.group` to 1 means the OOM granularity would be one entire command execution and any children it might've forked. or even by polling the memory stats and taking action faster than the kernel's oom-killer, like oomd does.
-
@cliffle@hachyderm.io 2026-04-14 05:10
@regehr I think the main reason the OOM killer is wrong is that it's having to do its job with very little information or context, acting after the fact. What you're proposing is basically an application-aware version, which seems reasonable.
-
@dotstdy@mastodon.social 2026-04-14 05:18
@regehr on Linux one interesting thing might be to launch initially into a conservatively limited cgroup, and then if the process dies restart it in a larger one. That might help avoid issues where you burst over the limit without being able to react fast enough.
-
@cks@mastodon.social 2026-04-14 14:54
@regehr I think you can sort of do this on an ad-hoc basis with systemd's 'run in a separate cgroup' stuff in systemd-run and systemd-oomd, but you'd need to teach your build manager to retry if a job was abruptly killed as opposed to exited with a bad status. (You could do the cgroup stuff through front end scripts for gcc/clang/lld/etc/etc, stuffing each command into a subordinate cgroup. More elaborate would be to monitor PSI information and not start commands until it was low enough.)