Date: Fri, 31 Mar 2017 16:51:59 -0700 From: Mark Millard <markmi@dsl-only.net> To: Brooks Davis <brooks@freebsd.org>, Dimitry Andric <dim@FreeBSD.org>, FreeBSD Ports <freebsd-ports@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Message-ID: <F315A080-0989-4521-A899-A0A06721934B@dsl-only.net> In-Reply-To: <FDFF229D-B9DB-4798-8743-01CAF218BD09@dsl-only.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> <F6F4B285-5D72-4B14-A12E-3D789AED063C@dsl-only.net> <FDFF229D-B9DB-4798-8743-01CAF218BD09@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Mar-30, at 7:51 PM, Mark Millard <markmi@dsl-only.net> wrote:
> On 2017-Mar-30, at 1:22 PM, Mark Millard <markmi@dsl-only.net> wrote:
>=20
>> Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique
>> would not change the "WITNESS and INVARIANTS"-like part of the
>> issue. In fact if WITH_DEBUG=3D causes the cmake debug-style
>> llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not
>> make any difference: separate enforcing of lack of optimization.
>>=20
>> But just to see what results I've done "pkg delete llvm40"
>> and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D
>> and its supporting code in place in addition to using WITH_DEBUG=3D
>> as the type of build fro FreeBSD's viewpoint.
>>=20
>> If you know that the test is a waste of machine cycles, you can
>> let me know if you want.
>=20
> The experiment showed that ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG
> use made no difference for devel/llvm40 so devel/llvm40 itself
> has to change such as what Dimitry Andric reported separately
> as a working change to the Makefile .
>=20
> (ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG would still have its uses
> for various other ports.)
I've now tried with both ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG and:
# svnlite diff /usr/ports/devel/llvm40/
Index: /usr/ports/devel/llvm40/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/ports/devel/llvm40/Makefile (revision 436747)
+++ /usr/ports/devel/llvm40/Makefile (working copy)
@@ -236,6 +236,11 @@
=20
.include <bsd.port.pre.mk>
=20
+.if defined(WITH_DEBUG)
+CMAKE_BUILD_TYPE=3D RelWithDebInfo
+STRIP=3D
+.endif
+
_CRTLIBDIR=3D =
${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd
.if ${ARCH} =3D=3D "amd64"
_COMPILER_RT_LIBS=3D \
pkg delete after the build reports:
Installed packages to be REMOVED:
llvm40-4.0.0
Number of packages to be removed: 1
The operation will free 42 GiB.
So down by 7 GiBytes from 49 GiBytes.
(I did not actually delete it.)
Also:
# du -sg /usr/obj/portswork/usr/ports/devel/llvm40
102 /usr/obj/portswork/usr/ports/devel/llvm40
which is down by 16 GiBytes from 118 GiBytes.
Reminder: These are from portmaster -DK so no
cleanup after the build, which is what leaves
the source code and such around in case of
needing to look at a problem.
(102+42) GiBytes =3D=3D 146 GiBytes.
vs.
(118+49) GiBytes =3D=3D 167 GiBytes.
So a difference of 21 GiBytes (or so).
But that is for everything in each case (and
WITH_DEBUG=3D in use):
# more /var/db/ports/devel_llvm40/options
# This file is auto-generated by 'make config'.
# Options for llvm40-4.0.0.r4
_OPTIONS_READ=3Dllvm40-4.0.0.r4
_FILE_COMPLETE_OPTIONS_LIST=3DCLANG DOCS EXTRAS LIT LLD LLDB
OPTIONS_FILE_SET+=3DCLANG
OPTIONS_FILE_SET+=3DDOCS
OPTIONS_FILE_SET+=3DEXTRAS
OPTIONS_FILE_SET+=3DLIT
OPTIONS_FILE_SET+=3DLLD
OPTIONS_FILE_SET+=3DLLDB
So avoiding WITH_DEBUG=3D and/or various build options
is still the major way of avoiding use of lots of space
if it is an issue.
Why no RAM+SWAP total report this time:
As far as I know FreeBSD does not track or report peak
swap-space usage since the last boot. And, unfortunately
I was not around to just sit and watch a top display this
time and I did not set up any periodic recording into a
file.
That is why I've not reported on the RAM+SWAP total
this time. It will have to be another experiment
some other time.
[I do wish FreeBSD had a way of reporting peak swap-space
usage.]
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F315A080-0989-4521-A899-A0A06721934B>