On Fri, Sep 27, 2024 at 01:48:23PM +0200, Christian Schulte wrote: > 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.
I was referring to "slower" as measured in wall time. Anyway, there are so many things that might affect your QEMU guest performance that it just doesn't make sense to use bare metal compile times as a benchmark (and, as you have pointed out, by noting Linux also has issues, this has nothing to do with OpenBSD). > > -- > Christian > --
