Post #1151371
2026-04-14 04:52 UTC
Replies (9)
-
@regehr@mastodon.social 2026-04-14 04:53
like, Linux's OOM killer is often wrong-- but this way of killing big-memory processes should be workable and largely consequence-free, since the build manager would only ever kill its own (hopefully idempotent) subprocesses
-
@gray17@mastodon.social 2026-04-14 05:51
@regehr choom might help? https://man7.org/linux/man-pages/man1/choom.1.html
-
@ianh@mastodon.social 2026-04-14 06:33
@regehr this sounds similar to XNU's concept of purgeable memory but applied to an entire process. like, ideally the OS itself would have a concept of a process which can be killed with only a performance impact (and e.g. its parent process would detect the death and re-run it some other time) rather than having the build manager attempt to detect the OOM condition (which seems difficult to make reliable)
-
@jaseg@chaos.social 2026-04-14 06:51
@regehr @whitequark you might be able to emulate that in a build-system agnostic way by allowing processes to swap, then having a little background script pause (SIGSTOP) them while the system is under memory pressure, and unpause them after the system has recovered
-
@david_chisnall@infosec.exchange 2026-04-14 06:58
@regehr There are build systems with configurable retry, but avoiding the OOM killer is not my main reason for limiting link jobs to 1. LLD is multithreaded and linking is almost embarrassing parallel and so running two link jobs at a time doesn’t speed things up, but it does make cache usage much worse, and additional time slicing means the linker has to do more work stealing. Even on a system with enough memory for the link jobs to all fit in, running the sequentially is normally faster. Oh, and the amount of anonymous memory that the linker owns tends not to be that big. Less than clang compiling a big C++ file. It’s mostly mmap’d .o files. If the OOM killer’s heuristics are sensible, these won’t count because they can be kicked out of the buffer cache for free (pulling them back in is slow, which is another reason you want to do the links sequentially).
-
@matus_chochlik@mastodon.online 2026-04-14 07:28
@regehr In 2020 I did a talk about something similar; a wrapper executable around ld/lld/gold/whatever, that allowed to limit how many concurrent instances of a specific executable are executed at a particular time. If more than the specified limit were launched, they were queued and executed later. I even had an extension, that used an ML classifier to examine the parameters and input files passed to the linker and set the limit dynamically. I still have the PDF and code if you're interested.
-
@shelldozer@oldbytes.space 2026-04-14 07:51
@regehr Assuming that the latter will avoid The OOM Killer. Otherwise it would end up being an expensive version of an infinite loop.
-
@funkylab@mastodon.social 2026-04-14 08:45
@regehr in fact, yes, there where attempts to upstream mem pressure based job spawn limits to ninja (just as there are "load" based ones), they never made it
-
@GyrosGeier@hachyderm.io 2026-04-16 15:59
@regehr I think this should be a kernel feature. There is a scheduling class, SCHED_BATCH, with low priority and very long (1.5s) slices. I think this could be improved even further, by essentially making the slices infinite, yielding CPU in execve() at the point where the process image is smallest, and on memory pressure, swap out the other batch class processes, smallest first. When there are free CPUs, resume the largest batch process. Users would just `make -j` with no limit.