From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 75237385DC2E; Wed, 26 Aug 2020 10:04:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 75237385DC2E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 0C6882829D7; Wed, 26 Aug 2020 12:04:56 +0200 (CEST) Date: Wed, 26 Aug 2020 12:04:56 +0200 From: Jan Hubicka To: "marxin at gcc dot gnu.org" Cc: gcc-bugs@gcc.gnu.org Subject: Re: [Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization Message-ID: <20200826100456.GC3909@kam.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 10:04:58 -0000 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794 > > --- Comment #2 from Martin Liška --- > (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. Aha, so it is extra locking mechanizm we add without jobserver knowledge. > > > > 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. 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. Honza