Re: Building -current incrementally.

On 9/27/24 11:21, Zé Loff wrote:
>
> On Fri, Sep 27, 2024 at 09:39:07AM +0200, Christian Schulte wrote:
>> On 9/26/24 10:43, Stuart Henderson wrote:
>>> On 2024-09-26, Christian Schulte <cs@schulte.it> wrote:
>>>> I am keen on knowing how those snapshots are build. Do they really wipe
>>>> out everything and then do a fresh build - lasting nearly 24h here for
>>>> me. I doubt it.
>>>
>>> That's how I do base+x "make build" and "make release" when I do them.
>>>
>>> 24h is a long time. Are you using very slow machines or did you just not
>>> use -j?
>>>
>>
>> time doas make build
>>
>> chown root:wheel /tmp/_etcdir.ajLXZ6LHx1/var/sysmerge/etc.tgz
>> chmod 644 /tmp/_etcdir.ajLXZ6LHx1/var/sysmerge/etc.tgz
>> 45014.21 real 32976.78 user 10507.23 sys
>>
>> Nearly 13h. Seems the host the guest is running on currently has I/O issues. A
>> linux guest on the same host also currently has issues. Lots of log messages
>> like these.
>>
>> kernel:[ 460.053622] watchdog: BUG: soft lockup - CPU#5 stuck for 75s! [kworker/5:0:42]
>>
>> Linux needs a reboot after those messages, OpenBSD just successfully ran a
>> make build.
>>
>> make -j does not make a lot of a difference. The disk I/O currently is just
>> very slow. Has nothing to do with OpenBSD.
>>
>> OpenBSD 7.6-current (GENERIC.MP) #12: Thu Sep 26 20:25:45 CEST 2024
>> schulte@0x02.schulte.it:/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 6425518080 (6127MB)
>> avail mem = 6207578112 (5920MB)
>> random: good seed from bootblocks
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5a10 (10 entries)
>> bios0: vendor SeaBIOS version "rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org" date 04/01/2014
>> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> ^^^^^^^^^^^^^^^^
>
> You can't expect the build time in a QEMU guest to compare with the one
> from a "bare metal" machine. Of course it its slower. And I guess the
> I/O performance will be highly dependent on whatever else the QEMU host
> is running, and on how it prioritizes things.
>

I did not even expect time(1) to show accurate readings on that host
after make build.

--
Christian