GENERIC kernel (was Re: BeagleBone Crochet Build Problem)

[Mark Millard]

On 2017-Oct-2, at 11:46 AM, Russell Haley <russ.haley at gmail.com> wrote:

> On Mon, Oct 2, 2017 at 10:10 AM, Mark Millard <markmi at dsl-only.net> wrote:
>> [I'm not arguing against the points or questions:
>> just noting a specific technique for CPU-targeting
>> the built kernel code.]
>> 
>> On 2017-Oct-2, at 9:46 AM, Ian Lepore <ian at freebsd.org> wrote:
>> 
>>> . . .
>>>   A GENERIC kernel gives worse performance than a per-soc kernel for
>>>   virtually every soc since we have to compile for the lowest common
>>>   denominator (things like using software divide on systems that have
>>>   hardware divide instructions).
>> 
>> I use src.conf files for CPU targeting, for both native and cross
>> building. For example (cross build):
>> 
>> # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.amd64-host
>> TO_TYPE=aarch64
>> TOOLS_TO_TYPE=${TO_TYPE}
>> #
>> KERNCONF=GENERIC-NODBG
>> TARGET=arm64
>> .if ${.MAKE.LEVEL} == 0
>> TARGET_ARCH=${TO_TYPE}
>> .export TARGET_ARCH
>> .endif
>> #
>> WITH_CROSS_COMPILER=
>> WITHOUT_SYSTEM_COMPILER=
>> #
>> WITH_LIBCPLUSPLUS=
>> WITHOUT_BINUTILS_BOOTSTRAP=
>> WITH_ELFTOOLCHAIN_BOOTSTRAP=
>> WITH_CLANG_BOOTSTRAP=
>> WITH_CLANG=
>> WITH_CLANG_IS_CC=
>> WITH_CLANG_FULL=
>> WITH_CLANG_EXTRAS=
>> WITH_LLD_BOOTSTRAP=
>> WITH_LLD=
>> WITH_LLD_IS_LD=
>> WITH_LLDB=
>> #
>> WITH_BOOT=
>> WITHOUT_LIB32=
>> #
>> WITHOUT_GCC_BOOTSTRAP=
>> WITHOUT_GCC=
>> WITHOUT_GCC_IS_CC=
>> WITHOUT_GNUCXX=
>> #
>> NO_WERROR=
>> #WERROR=
>> MALLOC_PRODUCTION=
>> #
>> WITH_REPRODUCIBLE_BUILD=
>> WITH_DEBUG_FILES=
>> #
>> XCFLAGS+= -mcpu=cortex-a53
>> XCXXFLAGS+= -mcpu=cortex-a53
>> # There is no XCPPFLAGS but XCPP gets XCFLAGS content.
>> 
>> 
>> And for native I used the C<?>FLAGS.clang notation:
>> 
>> # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host
>> TO_TYPE=aarch64
>> TOOLS_TO_TYPE=${TO_TYPE}
>> #
>> KERNCONF=GENERIC-NODBG
>> TARGET=arm64
>> .if ${.MAKE.LEVEL} == 0
>> TARGET_ARCH=${TO_TYPE}
>> .export TARGET_ARCH
>> .endif
>> #
>> #WITH_CROSS_COMPILER=
>> WITH_SYSTEM_COMPILER=
>> #
>> #CPUTYPE=soft
>> WITH_LIBCPLUSPLUS=
>> WITHOUT_BINUTILS_BOOTSTRAP=
>> WITH_ELFTOOLCHAIN_BOOTSTRAP=
>> #WITHOUT_CLANG_BOOTSTRAP=
>> WITH_CLANG=
>> WITH_CLANG_IS_CC=
>> WITH_CLANG_FULL=
>> WITH_CLANG_EXTRAS=
>> WITH_LLD_BOOTSTRAP=
>> WITH_LLD=
>> WITH_LLD_IS_LD=
>> WITH_LLDB=
>> #
>> WITH_BOOT=
>> WITHOUT_LIB32=
>> #
>> WITHOUT_GCC_BOOTSTRAP=
>> WITHOUT_GCC=
>> WITHOUT_GCC_IS_CC=
>> WITHOUT_GNUCXX=
>> #
>> NO_WERROR=
>> #WERROR=
>> MALLOC_PRODUCTION=
>> #
>> 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-a53
>> CXXFLAGS.clang+= -mcpu=cortex-a53
>> CPPFLAGS.clang+= -mcpu=cortex-a53
>> 
>> 
>> . . .
>> 
>> ===
>> Mark Millard
>> markmi at dsl-only.net
> 
> What advantage do does this confer to your testing?

My use is personal-interest use. I've no reason to bother
disabling things from GENERIC: I include GENERIC and
override to produce non-debug. (That is a head/ example,
not stable/ or release/ or releng/ .) But I also have no
reason to have the kernel's machine code portable across
various subfamilies.

On the lower power, lower performance types of hardware
that I have access to I bias towards tailoring to the
CPU type. (I do not have access to any BIG.little
configurations were code common to the mix might be
important. But to my knowledge FreeBSD does not support
any BIG.little combinations anyway.)

[There was an occasion where my use of -mcpu helped
identify/confirm a point/presumption that need not
hold. But I'm not the only one that does such
tailoring.]

I normally do not use the snapshots or releases. I do not
bias the builds for old PowerMac's to match CPU details for
what I have access to (beyond powerpc64 vs. powerpc that
is already involved).

As for why I wrote about it: the CPU type for kernel
builds can be controlled outside the kernel-config files,
at least within a family:

For armv6 the GENERIC kernel configuration files already
indicate the more generic armv7 classification. I just
pick a more specific member of the family. aarch64 has
a similar status. I would not try to step outside a
family with the src.conf way of specifying CPUs.
(Something that I probably should have mentioned in the
original message.)

Also: I'd guess that Ian builds kernels rather than
using the "standard" ones. It was his text that I was
replying to. He likely knew anyway but his note might
leave a misimpression about alternatives for that
specific issue.

It is one thing to have GENERIC span some of the small,
low power SOC's and boards. It is another to have only
GENERIC for them. (But for my use GENERIC-based is
fine so I do not have an example that would drive the
FreeBSD choice on the issue.)


===
Mark Millard
markmi at dsl-only.net