Date: Wed, 23 Jun 2021 17:58:56 -0700 From: Mark Millard via freebsd-ports <freebsd-ports@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD ports <freebsd-ports@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: llvm10 build failure on Rpi3 Message-ID: <43B69E69-AF38-4B50-8018-BCA02A5BBAAA@yahoo.com> In-Reply-To: <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <DD8D8FE1-F02E-4A25-8F2B-5672F10E7268@yahoo.com> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Misc notes . . . Looking at your logs, I expect trying to build both llvm10 and rust in parallel is likely to run into resource issues on teh RPi3B+. For builds in that context, it may be better to do something like: # poudriere buld -j main devel/llvm10 # poudriere buld -j main lang/rust # poudriere buld -j main -f SOMEFILE-LISTING-OTHER-ORIGINS based on using ALLOW_MAKE_JOBS=3Dyes . Part of this I based on your on-going llvm10-10.0.1_5 build shows load averages (example): 4.53 4.49 4.40 so all 4 cores are busy with a little backlogged work already. It is also part of the explanation for: bad_C++_code 24:30:53 for both building at the same time vs. bad_C++_code 06:59:12 for only llvm10 building. (I'm not making claims for overall elapsed time.) You wrote in http://www.zefox.org/~bob/readme : MAX_EXECUTION_TIME_PACKAGE=3D432000 (since increased to 1724000, builds = still stop at 24 hours)=20 I think you may have guessed wrong about what MAX_EXECUTION_TIME_PACKAGE covers: it is for after staging the build, just creating the package from the staged material. It is not for the overall time turning the port into a package. The time to build (through staging?) is controlled by something you have left commented out and have not adjusted: # This defines the max time (in seconds) that a command may run for a = build # before it is killed for taking too long. Default: 86400 #MAX_EXECUTION_TIME=3D86400 My prior notes had listed: # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: MAX_EXECUTION_TIME=3D432000 But the figures that I'd used never dealt with something like rust on something like an RPi3B+. So the figure may well be too small even if rust is never built in parallel with anything else. (A similar point goes for all my example MAX_EXECUTION_TIME* figures.) I did do various llvm* builds, but rust is bigger than any one of those by a long shot. Parallel builds of things like llvm10 and rust in significantly overlapping time frames put the load average well over 4 and likely cause periods if significant paging/swapping. This can greatly expand the elapsed-time for the individual jobs (builders). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43B69E69-AF38-4B50-8018-BCA02A5BBAAA>