https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #1) > > As seen > > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg > > > > each blocking linking of a GCC front-end leads to a wasted jobserver worker. > Hmm, I am not sure how to interpret the graph. I can see that there is a > funny staircase of ltranses but how that relates to jobserver workers? Yes, I mean the staircase of LTRANS because at the beginning N-1 links are waiting for lock: [ 299s] lock-and-run.sh: (PID 7351) waiting 0 sec to acquire linkfe.lck from PID 7347 ... For jobserver they are still running even though they sleep. > 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. > > NUmber of partitions is currently 128 what is 100% of CPU usage for you? It's written in the graph footnote "CPU count: 16".
