11-STABLE buildworld is painfully slow now

mb2015

mb2015

I am trying to do a full update of my 11-STABLE armv6 system (a BeagleBone Black). When I did the same thing last year around this time, and the year before, buildworld took about 26 hours. But now, it has been running for 45 hours and still is not finished. It has been working on llvm/clang stuff for hours, which makes me think it is not even close to being done.

It's not stalled. It's barely using swap. I've been keeping all non-essential services shut off, so there's no bottlenecks that I know of.

Has something changed in 11-STABLE in the past year that would result such a dramatically longer buildworld time?
 
There have been discussions in the mailing lists. The recommendation has been to disable things as below in /etc/src.conf if they are not necessary for the system.
Code: 
WITHOUT_CLANG_EXTRAS=yes
WITHOUT_CLANG_FULL=yes
WITHOUT_LLDB=yes
 
This won’t be helpful for your current situation, but have you ever thought cross-building world and kernel for the Arm architecture on a faster system, since cross-building support is included in the FreeBSD build system. That would considerably shorten the process. Instead of days (26, >45 hours), a few hours, at most, or even shorter.
 
Thanks for those /etc/src.conf suggestions. I will start over with those and see how it goes.

About a year and a half ago I tried cross-building in a VirtualBox VM on my Win7 desktop (a Core i5-2400 3.4 GHz, with 2 cores devoted to the VM). I was disappointed to find that it wasn't going much faster at all and would only be saving a few hours at most. I probably wasn't doing it right? It was also not clear to me what the ideal procedure is to get the compiled code installed on the remote machine.
 
In VirtualBox, try increasing the number of CPU’s, if possible, allocate more base memory.

Important - in "Storage" create an SATA storage device controller (by default an IDE storage device controller is created, with a far lesser transfer rate, delete that after initial virtual machine setup).

You can add an existing vitual hard disk (.vdi) with FreeBSD already installed to the SATA controller or create a new one. Mark the .vdi disk "Solid-state Drive" in Storage -> Storage Devices -> <FreeBSD>.vdi -> Attributes.

Delete old /usr/obj, if there is enough RAM use a tmpfs() filesystem, use the -j option in buildworld, use devel/ccache (more info here), perform as few as possible tasks on the guest system.

Even with the mentioned methods it can’t be compared to a native FreeBSD installation on a physical disk, with full access to the hardware. If you have a spare disk (or you could share a partition on an existing hard disk) and a today’s usual hardware (cpu 4+ cores + hyper threading, 8+GB RAM), I would go that way. Together with temporal file system, running multiple jobs, using ccache will reduce the build time considerably.
mb2015 said:
....
It was also not clear to me what the ideal procedure is to get the compiled code installed on the remote machine.
Click to expand...
With nfsroot https://www.freebsd.org/doc/handbook/network-diskless.html (the same in the cross-building wiki, DESTDIR environment variable)
 
Thanks. After a near disaster in the past, I'm unwilling to risk screwing up the boot loader on my Win7 box, so there will be no installing FreeBSD on a spare partition. I've maxed out the number of attached drives as well.

No luck with those /etc/src.conf additions. Maybe they do help overall build time, but 46 hours in, it's basically at the same point as in the first attempt.

I saw in the -stable mailing list archive a mention of build times being triple what they were before. Guess I just have to wait.

[Edit:] Finally done with buildworld after 58 hours.
 
You must log in or register to reply here.
Back
Top