Re: Resolved: devel/llvm13 build: "ninja: build stopped: subcommand failed"

Hi Mark,

I use TMPFS=no and I don't have WITH_DEBUG set.
I will test with MAKE_JOBS_NUMBER=n in /usr/local/etc/poudriere.d/make.conf
and see what max n I can get it to compile and observe used ram+swap.

Other possibility is to increase swap to <=60GB but I'd like to avoid that
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 à(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 <=60GB
> >>>
> >>> . . .
> >>
> >>
> >> 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.
> >>
> >> ===
> >> 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=264949
> >
>
> 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=no 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= 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.
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

-- 
Nuno Teixeira
FreeBSD Committer (ports)