Date: Mon, 15 Aug 2022 14:05:33 +0100 From: Nuno Teixeira <eduardo@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: Resolved: devel/llvm13 build: "ninja: build stopped: subcommand failed" Message-ID: <CAFDf7U%2Biu4iZM9UHgff819SbDCbsKMJoMg_t2pbyCWSULoD7cA@mail.gmail.com> In-Reply-To: <4D8AB2F3-6A76-4E3A-9C44-348F1352A5D3@yahoo.com> References: <1D4C14BD-8955-4B86-9C99-3E58D7603122.ref@yahoo.com> <1D4C14BD-8955-4B86-9C99-3E58D7603122@yahoo.com> <CAFDf7UK-pAFXCrZZA9veASaa-wf9HKMdX52fxmcmDgRFiNOF7A@mail.gmail.com> <7CDC63F3-8B68-420E-8012-B1692667E293@yahoo.com> <CAFDf7UJmBNvfVo3SAenPUk1WkFgvpkqoM6=Riv6pwaovuNnAWg@mail.gmail.com> <21FC1F5E-240E-4A8C-A5D2-6B73494026C0@yahoo.com> <CAFDf7ULAPa-YcYezUDCAVP-cMijYLMpLM10z7Xom%2B1siXvn42g@mail.gmail.com> <3E3F8980-8214-45E9-9530-D78243A29D41@yahoo.com> <CAFDf7U%2BDbO0KFKnS4sx4AiXTsS_CPbKFyPTT-B0o1oZS9rWYAg@mail.gmail.com> <DF02B075-78C1-4142-9ACA-12C4CCAFBCF6@yahoo.com> <20220815120616.0cb809413a551717cab3a2eb@dec.sakura.ne.jp> <4D8AB2F3-6A76-4E3A-9C44-348F1352A5D3@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <marklmi@yahoo.com> escreveu no dia segunda, 15/08/2022 =C3=A0= (s) 04:26: > On 2022-Aug-14, at 20:06, Tomoaki AOKI <junchoon@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://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 <div dir=3D"ltr"><div>Hi Mark,</div><div><br></div><div>I use TMPFS=3Dno an= d I don't have WITH_DEBUG set.</div><div>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.<br></div><div><br></div><div>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.</div><div>What y= ou think about increasing swap?</div><div><br></div><div>Thanks<br></div></= div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Ma= rk Millard <<a href=3D"mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>&g= t; escreveu no dia segunda, 15/08/2022 =C3=A0(s) 04:26:<br></div><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex">On 2022-Aug-14, at 20:06, Tomoaki A= OKI <<a href=3D"mailto:junchoon@dec.sakura.ne.jp" target=3D"_blank">junc= hoon@dec.sakura.ne.jp</a>> wrote:<br> <br> > On Sun, 14 Aug 2022 12:23:03 -0700<br> > Mark Millard <<a href=3D"mailto:marklmi@yahoo.com" target=3D"_blank= ">marklmi@yahoo.com</a>> wrote:<br> > <br> >> On 2022-Aug-14, at 11:07, Nuno Teixeira <<a href=3D"mailto:edua= rdo@freebsd.org" target=3D"_blank">eduardo@freebsd.org</a>> wrote:<br> >> <br> >>> I will follow <a href=3D"https://docs.freebsd.org/en/books/han= dbook/book/#disks-growing" rel=3D"noreferrer" target=3D"_blank">https://doc= s.freebsd.org/en/books/handbook/book/#disks-growing</a> 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.<br> >>> <br> >>> I've tooked a note about total swap <=3D60GB<br> >>> <br> >>> . . .<br> >> <br> >> <br> >> I forgot an important question relative to the resource use<br> >> for building devel/llvm13 and later: do you need/want the<br> >> fortran compiler?<br> >> <br> >> If not, you can disable the options: FLANG MLIR<br> >> (building FLAG would require building MLIR)<br> >> <br> >> Then the build will be far less memory intensive<br> >> and take less time.<br> >> <br> >> It had slipped my mind that my builds have these 2 options<br> >> disabled.<br> >> <br> >> =3D=3D=3D<br> >> Mark Millard<br> >> marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target= =3D"_blank">yahoo.com</a><br> > <br> > Is there any possibility that something alike Bug 264949 [1] for gcc11= <br> > is happening?<br> > <br> > For amd64, option GOLD (LTO support) is implied by default.<br> > If it causes LTO to be enabled for llvm13 build itself, and lld act as= <br> > linker of gcc11, small TMPDIR would overflow.<br> > <br> > gcc11 required at minimum 5GiB of free space on TMPDIR.<br> > (4GiB was insufficient.)<br> > <br> > [1] <a href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264= 949" rel=3D"noreferrer" target=3D"_blank">https://bugs.freebsd.org/bugzilla= /show_bug.cgi?id=3D264949</a><br> > <br> <br> Nuno had a specific problem others have not reported:<br> <br> QUOTE<br> I've tested it but it still fails:<br> ---<br> pid 64502 (c++), jid 7, uid 65534, was killed: failed to reclaim memory<br> swap_pager: out of swap space<br> ---<br> on a Lenovo Legion 5, 16GB RAM and 4GB swap.<br> END QUOTE<br> <br> "was killed: failed to reclaim memory" and "swap_pager: out = of swap<br> space" are not about "small TMPDIR overflow", at least not d= irectly.<br> <br> But if the tmpfs is of a form backed by RAM+SWAP, then the tmpfs<br> use can grow to contribute to causing reclaim problems and/or out of<br> swap space problems by competing for RAM+SWAP space.<br> <br> Nuno reported having disabled such tmpfs use ( via USE_TMPFS=3Dno in<br> /usr/local/etc/poudriere.conf ). I do not know if that status is<br> well confirmed or not. I've also no clue if WITH_DEBUG=3D might be<br> in use. (WITH_DEBUG needs to not be in use unless huge resources are<br> available.)<br> <br> My amd64 tests indicate that something beyond the compiles/links<br> themselves was using significant RAM+SWAP in Nuno's context. I've<b= r> no clue what.<br> <br> =3D=3D=3D<br> Mark Millard<br> marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_blank= ">yahoo.com</a><br> <br> </blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g= mail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(102,102,102)">Nun= o Teixeira<br>FreeBSD Committer (ports)</span></div></div> --0000000000005c901b05e6474a53--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7U%2Biu4iZM9UHgff819SbDCbsKMJoMg_t2pbyCWSULoD7cA>