https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #11 from Michael Matz <matz at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #10) > > We could also punt: when enable-link-mutex we could artificially up the job > > number for make to account for the waiting link steps. I.e. when normally > > -jN > > was given, the link step could be done under -j(N + nr-language - 1). That > > would lead to the > > nr-of-languages-1 job server tokens taken up by the sleeping link steps to > > be > > accounted for, and hence the (single running) link step still be able to > > use N > > threads/processes in parallel. > > I do not think it is easy to do with current make jobserver. The > toplevel jobserver opens the pipi with -jN many tokens and all other > makes connect to it. It does not provide interface to return a token > and re-take it unless we implement it of course. Sure, but that's not the only way the above punting could be done. The parallel phase that currently communicates with the jobserver essentially tries to get N tokens. It could be changed to assume that there are implicitely nr-of-languages-1 more tokens available. I.e. the number of threads/processes would always be enlarged by nr-of-languages-1, even without any tokens from the jobserver.
