Re: RPI4 clock speeds and serial port ( temperatures idle and -j4 buildworld buildkernel )

On 2021-Mar-19, at 11:55, tech-lists <tech-lists at zyxst.net> wrote:

> On Fri, Mar 19, 2021 at 11:29:51AM -0700, Mark Millard via freebsd-arm wrote:
> 
>> Back to temperature. See:
>> 
>> https://www.raspberrypi.org/documentation/hardware/raspberrypi/frequency-management.md
>> 
>> It indicates that 85C is the maximum temperature,
>> though lower figures can be set. It also reports
>> that a form of throttling starts at 80C by default.
> 
> I use -j6 [1] for buildworld/kernel steps

I'll put my -jN notes after [1].

> on stable/13 and highest temp seen has been 72 degC at 25 ambient [2], when it's compiling clang and friends. Not measured
> timings but it's less than a day.

I like getting the time down to near 8 hours or less,
allowing a build to start before bed and be finished
not that long after getting out of bed, even for a
full rebuild.

The RPi4B's are the first of the small boards that
I've gotten into that range for the build times for
what I choose to build for buildworld buildkernel .

> I'll have to try the .clang flags
> you've posted elsewhere. What I do have, which cuts down compile time,
> is a load of WITHOUT_SOMETHING= statements in /etc/src.conf covering stuff that'll
> never be used in this particular context.

For building on arm's, I have the WITHOUT_*'s for
the other instruction sets for building the compiler
but all my src.conf equivalents have some other stuff
enabled that is not default relative to llvm/clang.
Other parts of FreeBSD I've not controlled explicitly.

I show the file later in this message.

> [1] still has enough horsepower to run eg mutt+vim and a nginx webserver comfortably.     I didn't choose -j6 out of anything more scientific than "well there's 4 cores so     let's make it j6 to keep it busy"

The 8 GiByte RPi4B's have enough RAM to not have as much
negative consequences from -j6 from the extra RAM use.
But I tend to use similar configuration handling across
systems --and that ends up being driven by the lower RAM
contexts for such issues.

Also, in monitoring builds with -j4 and larger it never
looked to me like there was much idle time that a -j5 or
more would actually put to use. (A similar statement is
true for -j32 vs. -j33 or more for the ThreadRipper 1950X
context. This context has lots of RAM for such activity.)
I've not done such experiments in a long time.

> [2] implying maximum ambient is 33 for this case.


Notes . . .

I probably should have listed my equivalent of
src.conf when I listed the kernel configuration
file in the earlier messages, since it contributes
to the time use in (re)builds and so to what my
reported times are for. So:

# more ~/src.configs/src.conf.cortexA72-clang-bootstrap.aarch64-host 
TO_TYPE=aarch64
#
KERNCONF=GENERIC-NODBG
TARGET=arm64
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_SYSTEM_COMPILER=
WITH_SYSTEM_LINKER=
#
WITH_ELFTOOLCHAIN_BOOTSTRAP=
#Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL=
WITH_LLVM_TARGET_AARCH64=
WITH_LLVM_TARGET_ARM=
WITHOUT_LLVM_TARGET_MIPS=
WITHOUT_LLVM_TARGET_POWERPC=
WITHOUT_LLVM_TARGET_RISCV=
WITHOUT_LLVM_TARGET_X86=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLD_IS_LD=
WITH_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
#
WITHOUT_WERROR=
#WERROR=
MALLOC_PRODUCTION=
WITH_MALLOC_PRODUCTION=
WITHOUT_ASSERT_DEBUG=
WITHOUT_LLVM_ASSERTIONS=
#
# Avoid stripping but do not control host -g status as well:
DEBUG_FLAGS+=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
# Use of the .clang 's here avoids
# interfering with other C<?>FLAGS
# usage, such as ?= usage.
CFLAGS.clang+= -mcpu=cortex-a72
CXXFLAGS.clang+= -mcpu=cortex-a72
CPPFLAGS.clang+= -mcpu=cortex-a72
ACFLAGS.arm64cpuid.S+=  -mcpu=cortex-a72+crypto
ACFLAGS.aesv8-armx.S+=  -mcpu=cortex-a72+crypto
ACFLAGS.ghashv8-armx.S+=        -mcpu=cortex-a72+crypto


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"