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 <c...@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
>>     schu...@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

Reply via email to