From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 23 Jul 2019 05:05:04 -0700 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8F94944BD1; Tue, 23 Jul 2019 12:05:03 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-52.ams2.redhat.com [10.36.117.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5EAC519C58; Tue, 23 Jul 2019 12:05:02 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] OvmfPkg: enable multiprocessor builds when using build.sh To: Jordan Justen , Ard Biesheuvel , Rebecca Cran , devel@edk2.groups.io References: <20190722005816.96146-1-rebecca@bsdio.com> <156377947230.31344.9139528030621143554@jljusten-skl> <5313f05d-cd57-3fd0-9a44-4290b64db5a9@redhat.com> <156383729562.19762.9432602825677327108@jljusten-skl> <9733a473-7dc0-c8e4-18e5-0a1d0f80f3e0@redhat.com> <156386912527.18964.11550708881413954016@jljusten-skl> From: "Laszlo Ersek" Message-ID: <22ec34d0-cd72-f91d-6743-a322ae42716a@redhat.com> Date: Tue, 23 Jul 2019 14:05:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <156386912527.18964.11550708881413954016@jljusten-skl> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 23 Jul 2019 12:05:03 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/23/19 10:05, Jordan Justen wrote: > On 2019-07-23 00:44:06, Laszlo Ersek wrote: >> On 07/23/19 02:00, Rebecca Cran wrote: >>> On 2019-07-22 17:14, Jordan Justen wrote: >>>> >>>> I was suggesting that if they didn't specify -n as a param to >>>> build.sh, then build.sh should not send -n to the edk2 build command. >>>> The effect would be for the edk2 build command to check >>>> Conf/target.txt. By default, I think target.txt will not set >>>> THREADNUMBER, so "0" would still be the result. >>>> >>>> Yet, it would give them the option to set it in Conf/target.txt. >>>> Today, since we always use the -n param, target.txt is always ignored >>>> for this parameter. >>> >>> >>> On a related topic, I wonder if we should add a "-j" parameter if we >>> build BaseTools for users (e.g. "make -j4 -C BaseTools")? I've found >>> that it can be pretty slow without it: on my system adding -j4 reduces >>> build time from 55 seconds to 15. Going higher doesn't seem to produce >>> much more benefit: -j32 (on a ThreadRipper system) reduces it to 12 seconds. >>> >>> >> >> Passing >> >> -j $(getconf _NPROCESSORS_ONLN) >> >> to "make" (for building BaseTools) makes sense, IMO. > > I guess the concern might be that we'll be running a bunch of > make invocations in parallel, each trying to spawn a compilation for > each thread. O(n^2) compilations. :) > > In the make man-page for -j: "When make invokes a sub-make, all > instances of make will coordinate to run the specified number of jobs > at a time;", but I'm not sure if that's how `build -n` is implemented. > (With make...) > > Since python writes the makefiles, it could be used instead of > getconf, right? > > What we need is someone to make the ninja-build backend for BaseTools. > :) Wait, there are two separate topics here. (1) The "make" command we are discussing here is responsible solely for building the host-native BaseTools binaries, from the C and CPP sources under BaseTools: make -C $WORKSPACE/BaseTools This "make" command is not an ancestor of the actual firmware build. (2) Regarding the invocation of the "build" utility from an outer "make", such that you end up with "make -j" --> build --> "make": That's something we don't do in edk2 per se, but we *do* do it in edk2's bundling in QEMU. It raised some challenges, but ultimately, the innermost "make" processes will inherit such an environment from the outermost "make" that will enable a successful coordination between them, regardless of "-n 0" used with "build" in the middle. Basically, even if "build -n 0" starts twenty inner "make" processes, the job server in the outer "make" will ensure that no more than, say, 4, inner "make" processes are active at the same time. (Assuming 20 logical processors in the system, and "-j4" passed to the outer "make".) A related TianoCore BZ is: https://bugzilla.tianocore.org/show_bug.cgi?id=1607 --*-- Anyway, for "OvmfPkg/build.sh", item (2) is irrelevant; so changing make -C $WORKSPACE/BaseTools to make -C $WORKSPACE/BaseTools -j $(getconf _NPROCESSORS_ONLN) would be useful and safe. Thanks Laszlo