From nobody Mon Aug 15 13:05:33 2022 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M5vfP0J12z4YsyB for ; Mon, 15 Aug 2022 13:05:49 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M5vfN6R5cz3WBF for ; Mon, 15 Aug 2022 13:05:48 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660568748; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=URbG7Tai3rtTa3iWc9k7J+gAYLbe3vSnkBMxPe+amDc=; b=JMZlD0LIbaJ+KV68FutII57BNokAFDqR9M6gCL+DeSIMpgy5U6vR/9l9RfGbHWfMNoTGyZ BYlLFu49Lf2Zv/0rKEUMOnDucrhylVRMqgTD3jibehIgoUNOjy1KXd97DCvbPlHbI6/RrN IztXqirynO32Be4cKr1fG8Nz7hDtpq1zygcrRXVdD+GPZZZ3UDT/XMUGg6nB3034dIJKOY a6ddSVra4UbPbmN6CIR6Jqn/rv2TffOwAYyF6rVZQmSSmQQ2IgLGC0/cNdFOQHLRWxL0ud giGIt7b06sU7+RexJUlJJaiVTjyHrTtmlzV6+8nz01JuXMGd9VaAmOcB774+uQ== Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M5vfN5MDjzXxD for ; Mon, 15 Aug 2022 13:05:48 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-vk1-f176.google.com with SMTP id c22so3628084vko.7 for ; Mon, 15 Aug 2022 06:05:48 -0700 (PDT) X-Gm-Message-State: ACgBeo0vC7askma347yeqJOQkH+xZweZjS102Bgf/se3gLAty4ErtQH/ EVrPfnAwUmKVjYOcLbTJ5RZ1ab7/gTal91sZ8oc= X-Google-Smtp-Source: AA6agR7oZeig8GBG0pMNqz5DqAU0ACXpw/1Kb7uXGPzVtkjY0Gu2W5lpIta/g2zhwYWBnt5mT1BG+5gAxEOEukyaCXw= X-Received: by 2002:a1f:acd2:0:b0:37b:531:9988 with SMTP id v201-20020a1facd2000000b0037b05319988mr6269597vke.19.1660568748197; Mon, 15 Aug 2022 06:05:48 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <1D4C14BD-8955-4B86-9C99-3E58D7603122.ref@yahoo.com> <1D4C14BD-8955-4B86-9C99-3E58D7603122@yahoo.com> <7CDC63F3-8B68-420E-8012-B1692667E293@yahoo.com> <21FC1F5E-240E-4A8C-A5D2-6B73494026C0@yahoo.com> <3E3F8980-8214-45E9-9530-D78243A29D41@yahoo.com> <20220815120616.0cb809413a551717cab3a2eb@dec.sakura.ne.jp> <4D8AB2F3-6A76-4E3A-9C44-348F1352A5D3@yahoo.com> In-Reply-To: <4D8AB2F3-6A76-4E3A-9C44-348F1352A5D3@yahoo.com> From: Nuno Teixeira Date: Mon, 15 Aug 2022 14:05:33 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Resolved: devel/llvm13 build: "ninja: build stopped: subcommand failed" To: Mark Millard Cc: Tomoaki AOKI , FreeBSD Mailing List Content-Type: multipart/alternative; boundary="0000000000005c901b05e6474a53" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660568748; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=URbG7Tai3rtTa3iWc9k7J+gAYLbe3vSnkBMxPe+amDc=; b=lYzy2TwqD/ouT4869nZO5Q3spPpgZ4/fSciuD1kEsX/LtQJYaym4jPSOgzyVSdAOcWupKy qPt/sc5Y5bxxHswcr4edVUoAX1I+FZLg/11bP/A6fSz2KRAlFNrQBB/Q9/fYeY200oR6oB q83Gdp8VXjzf7WXAYV181dYvRYNadr5akPDfS57wSWLUzqGE5sz5sK2vqzzXOL+kObXpfq MieekFNXSthASUBSgTmtnVlbNQEVIPzfBukoLWknKjI1HjVhXsa5KIiY6A2jcijyaEe+BN 5BiwCpAOD6nNejO5bgcA8wosNdcbdKZOi0/i7FEYtlX83ClbCLZ8h+IccH22CQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660568748; a=rsa-sha256; cv=none; b=PKG0tZOPHfy3y8QPd3z3l0dI4kN6OhGu0WCx6dy8DUfnnZxLcniZhdNSszlvyDjKYBbHhf qJtzg881qAud+wS4AjaLX31kFNmSX/5+18ML0nwfxNFKQNFITisgl/AjFPtymv4Q/WbQRX y/4DyWTV9xjCsZT+w8DomYJO6btj/Hs+ml2Vlz9Qv1HdjVVzNYEHrNkBsxLNUqtwtRSInk g4R+bq0VtAng0+i0KocM/3JFGAvF4nIACn5SeXxKR+c4zHZ05+XzrR73x1f5ovdt1MBpfv VER49obs5Vdh9HQUS2ZmyJ9P9xkzvch3N/8gVLlCAAdAuwRg8JamIUjV2CbhnA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --0000000000005c901b05e6474a53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mark, I use TMPFS=3Dno and I don't have WITH_DEBUG set. I will test with MAKE_JOBS_NUMBER=3Dn in /usr/local/etc/poudriere.d/make.co= nf and see what max n I can get it to compile and observe used ram+swap. Other possibility is to increase swap to <=3D60GB but I'd like to avoid tha= t because I will need to resize freebsd-zfs partition. What you think about increasing swap? Thanks Mark Millard escreveu no dia segunda, 15/08/2022 =C3=A0= (s) 04:26: > On 2022-Aug-14, at 20:06, Tomoaki AOKI wrote: > > > On Sun, 14 Aug 2022 12:23:03 -0700 > > Mark Millard wrote: > > > >> On 2022-Aug-14, at 11:07, Nuno Teixeira wrote: > >> > >>> I will follow > https://docs.freebsd.org/en/books/handbook/book/#disks-growing and resize > actual swap, but before that I will have to make sure that backups are ok > in case of something goes wrong. > >>> > >>> I've tooked a note about total swap <=3D60GB > >>> > >>> . . . > >> > >> > >> I forgot an important question relative to the resource use > >> for building devel/llvm13 and later: do you need/want the > >> fortran compiler? > >> > >> If not, you can disable the options: FLANG MLIR > >> (building FLAG would require building MLIR) > >> > >> Then the build will be far less memory intensive > >> and take less time. > >> > >> It had slipped my mind that my builds have these 2 options > >> disabled. > >> > >> =3D=3D=3D > >> Mark Millard > >> marklmi at yahoo.com > > > > Is there any possibility that something alike Bug 264949 [1] for gcc11 > > is happening? > > > > For amd64, option GOLD (LTO support) is implied by default. > > If it causes LTO to be enabled for llvm13 build itself, and lld act as > > linker of gcc11, small TMPDIR would overflow. > > > > gcc11 required at minimum 5GiB of free space on TMPDIR. > > (4GiB was insufficient.) > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264949 > > > > Nuno had a specific problem others have not reported: > > QUOTE > I've tested it but it still fails: > --- > pid 64502 (c++), jid 7, uid 65534, was killed: failed to reclaim memory > swap_pager: out of swap space > --- > on a Lenovo Legion 5, 16GB RAM and 4GB swap. > END QUOTE > > "was killed: failed to reclaim memory" and "swap_pager: out of swap > space" are not about "small TMPDIR overflow", at least not directly. > > But if the tmpfs is of a form backed by RAM+SWAP, then the tmpfs > use can grow to contribute to causing reclaim problems and/or out of > swap space problems by competing for RAM+SWAP space. > > Nuno reported having disabled such tmpfs use ( via USE_TMPFS=3Dno in > /usr/local/etc/poudriere.conf ). I do not know if that status is > well confirmed or not. I've also no clue if WITH_DEBUG=3D might be > in use. (WITH_DEBUG needs to not be in use unless huge resources are > available.) > > My amd64 tests indicate that something beyond the compiles/links > themselves was using significant RAM+SWAP in Nuno's context. I've > no clue what. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD Committer (ports) --0000000000005c901b05e6474a53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

I use TMPFS=3Dno an= d I don't have WITH_DEBUG set.
I will test with MAKE_JOBS_NUM= BER=3Dn in /usr/local/etc/poudriere.d/make.conf and see what max n I can ge= t it to compile and observe used ram+swap.

Oth= er possibility is to increase swap to <=3D60GB but I'd like to avoid= that because I will need to resize freebsd-zfs partition.
What y= ou think about increasing swap?

Thanks

Ma= rk Millard <marklmi@yahoo.com&g= t; escreveu no dia segunda, 15/08/2022 =C3=A0(s) 04:26:
On 2022-Aug-14, at 20:06, Tomoaki A= OKI <junc= hoon@dec.sakura.ne.jp> wrote:

> On Sun, 14 Aug 2022 12:23:03 -0700
> Mark Millard <marklmi@yahoo.com> wrote:
>
>> On 2022-Aug-14, at 11:07, Nuno Teixeira <eduardo@freebsd.org> wrote:
>>
>>> I will follow https://doc= s.freebsd.org/en/books/handbook/book/#disks-growing and resize actual s= wap, but before that I will have to make sure that backups are ok in case o= f something goes wrong.
>>>
>>> I've tooked a note about total swap <=3D60GB
>>>
>>> . . .
>>
>>
>> I forgot an important question relative to the resource use
>> for building devel/llvm13 and later: do you need/want the
>> fortran compiler?
>>
>> If not, you can disable the options: FLANG MLIR
>> (building FLAG would require building MLIR)
>>
>> Then the build will be far less memory intensive
>> and take less time.
>>
>> It had slipped my mind that my builds have these 2 options
>> disabled.
>>
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>
> Is there any possibility that something alike Bug 264949 [1] for gcc11=
> is happening?
>
> For amd64, option GOLD (LTO support) is implied by default.
> If it causes LTO to be enabled for llvm13 build itself, and lld act as=
> linker of gcc11, small TMPDIR would overflow.
>
> gcc11 required at minimum 5GiB of free space on TMPDIR.
> (4GiB was insufficient.)
>
> [1] https://bugs.freebsd.org/bugzilla= /show_bug.cgi?id=3D264949
>

Nuno had a specific problem others have not reported:

QUOTE
I've tested it but it still fails:
---
pid 64502 (c++), jid 7, uid 65534, was killed: failed to reclaim memory
swap_pager: out of swap space
---
on a Lenovo Legion 5, 16GB RAM and 4GB swap.
END QUOTE

"was killed: failed to reclaim memory" and "swap_pager: out = of swap
space" are not about "small TMPDIR overflow", at least not d= irectly.

But if the tmpfs is of a form backed by RAM+SWAP, then the tmpfs
use can grow to contribute to causing reclaim problems and/or out of
swap space problems by competing for RAM+SWAP space.

Nuno reported having disabled such tmpfs use ( via USE_TMPFS=3Dno in
/usr/local/etc/poudriere.conf ). I do not know if that status is
well confirmed or not. I've also no clue if WITH_DEBUG=3D might be
in use. (WITH_DEBUG needs to not be in use unless huge resources are
available.)

My amd64 tests indicate that something beyond the compiles/links
themselves was using significant RAM+SWAP in Nuno's context. I've no clue what.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com



--
Nun= o Teixeira
FreeBSD Committer (ports)
--0000000000005c901b05e6474a53--