https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 26 Aug 2020, matz at gcc dot gnu.org wrote: > 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. I wonder whether the link-mutex is better be implemented with a set of artificial dependences. If we want to serialize building cc1, cc1plus, etc. then just have cc1: cc1plus cc1plus: ... ... and only conditionally enable those somehow. But IIRC nowadays that "waiting" also prints those progress markers ...
