https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> --- > > For jobserver they are still running even though they sleep. > Aha, so it is extra locking mechanizm we add without jobserver > knowledge. It's unrelated to jobserver, one can enable it with configure option mentioned in the title. > > > > > > > We limit makefile to link a binary at a time to avoid Richi's box getting > > > out of memory, right? > > > > No. It's because we want to have a reasonable contrains which is right now > > 8GB. > > Without --enable-link-mutex, we would consume ~ 10 x 1.3 GB (plus WPA > > parallel > > streaming peak), which is probably not desired. > > 10x1.3GB will get consumed only if the building machine has 10 threads. Typical OBS machine used for package build is either 8 (required minimum) or 16. > I wonder if the jobserver WPA streaming integration will happen this > year, with that snd some patches to WPA memory use we could fit in 8GB > unless very large parallelism is configured. > > I suppose only really effective solution would to teach the jobserver > that some jobs are "big" and consume multiple tokens, that is WPA, while > other jobs like ltranses and streaming are small. > > This is of course still not very pretty, but it is impossible to tell in > advance what job is big and what job is small. Sure, it's all quite compilicated. One needs to negotiate with jobserver :) I'm going to collect graph w/o --enable-link-mutex on my machine. > > Honza
