Re: RPi3B -j4 vs. -j3 main [so: 14] from-scratch buildworld times for my context; buildkernel too; swap space usage and such

From: Mark Millard <marklmi_at_yahoo.com>
Date: Thu, 25 May 2023 20:35:51 UTC
[Adding -j4 info for 4 GiByte, 1200 MHz, Rock64, using USB3 port for world (same media).]

On May 24, 2023, at 17:46, Mark Millard <marklmi@yahoo.com> wrote:

> RPi3B -j4 vs. -j3 buildworld times for my context:
> 
> World built in 120764 seconds, ncpu: 4, make -j4 [So a little under 33 hr 35 min]
> World built in 115635 seconds, ncpu: 4, make -j3 [So a little under 32 hr 10 min]
> [A delta of a little under 1hr 30min]

Rock64 -j4 buildworld for my context:

World built in 60637 seconds, ncpu: 4, make -j4 [So a somewhat under 16 hr 55 min]

> 
> So: -j4 buildworld spent more time waiting for its trashing of
> the swap space than time it gained from having use of a 4th
> core. The trashing is mostly during building of libllvm, libclang,
> and liblldb. The RPi3B RAM subsystem can limit the gain from
> having more cores active as well.
> 
> 
> By contrast . . .
> 
> RPi3B -j4 vs. -j3 buildkernel times for my context:
> 
> Kernel(s)  GENERIC-NODBG-CA53 built in 7836 seconds, ncpu: 4, make -j4 [So a little under 2 hr 15 min]
> Kernel(s)  GENERIC-NODBG-CA53 built in 8723 seconds, ncpu: 4, make -j3 [So a little under 2 hr 30 min]
> [A delta of a little under 15 min]

Rock64 -j4 buildkernel for my context:

Kernel(s)  GENERIC-NODBG-CA53 built in 4957 seconds, ncpu: 4, make -j4 [So a somewhat under 1 hr 25 min]

> So: -j4 buildkernel spent less time waiting for its trashing of
> the swap space than time it gained from having use of a 4th
> core. (Not much thrashing occurred.)
> 
> 
> And mem/swap usage info for buildworld+buildkernel . . .
> 
> Overall -j4 vs -j3 buildworld buildkernel info for my context:
> 
> -j4 Mem: . . ., 677688Ki MaxObsActive, 249652Ki MaxObsWired, 950032Ki MaxObs(Act+Wir+Lndry)
> -j3 Mem: . . ., 683416Ki MaxObsActive, 315140Ki MaxObsWired, 927424Ki MaxObs(Act+Wir+Lndry)

Rock64:

-j4 Mem: . . ., 1584Mi MaxObsActive,  741748K MaxObsWired, 2308Mi MaxObs(Act+Wir+Lndry)

> -j4 Swap: . . ., 1495Mi MaxObsUsed, 2117Mi MaxObs(Act+Lndry+SwapUsed), 2358Mi MaxObs(Act+Wir+Lndry+SwapUsed)
> -j3 Swap: . . ., 1178Mi MaxObsUsed, 1811Mi MaxObs(Act+Lndry+SwapUsed), 2049Mi MaxObs(Act+Wir+Lndry+SwapUsed)

Rock64:
(Note: The lack of MaxObsUsed for Swap is because it was never
       observed to be positive.)

-j4 Swap: 14746Mi Total, . . ., 1617Mi MaxObs(Act+Lndry+SwapUsed), 2308Mi MaxObs(Act+Wir+Lndry+SwapUsed)

> FYI for the context:
> make[1]: "/usr/main-src/Makefile.inc1" line 326: SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
> make[1]: "/usr/main-src/Makefile.inc1" line 331: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker.
> 
> 
> Notes:
> 
> Incremental buildworld's would depend on how much rebuilding of
> libllvm, libclang, and liblldb would happen to occur.
> 
> A system with 2 GiBytes of RAM would have far less trashing of
> the swap space. A system with 4 GiBytes of RAM would not thrash
> the swap space. The closest comparison I could make with 4
> GiBytes of RAM would be the Rock64 doing a from-scratch build.
> It is also cortex-a53 based. As I remember, its RAM subsystem
> does not limit multiple cores as easily/much. I've no access to
> an analogous 2 GiByte context.
> 

Note: The Rock64 U-Boot does not support the USB3 port
so I have the boot using 2 media in sequence:

A) The kernel and earlier stages booting via an e.MMC media.
B) The world then booting from the USB3 NVMe media.

The USB3 NVMe media used via a USB3 port has a higher
data rate context than for the RPi3B USB2 port context.

===
Mark Millard
marklmi at yahoo.com