svn commit: r356116 - head (powerpc families jumping to clang-based; powerpc64 also to ELFv2)

[Mark Millard]

Ronald Klop ronald-lists at klop.ws wrote on
Fri Dec 27 09:39:22 UTC 2019 :

QUOTE
Do powerpc people need to do something special while updating?
Like a clean buildkernel/buildworld. Or is this just a note for historical  
bookkeeping?
END QUOTE


See https://lists.freebsd.org/pipermail/freebsd-ppc/2019-December/011042.html

But it was -r356118 before powerpc64 and 32-bit powerpc
started to complete builds on ci.freebsd.org . powerpcspe
still fails to build there.

I agree that UPDATING could use more material guiding
actions, especially for powerpc64 where the ELFv1->ELFv2
change is an ABI incompatibility. Quoting from that
message:

QUOTE
Therefore, it is recommended to perform a complete reinstall of the
system on powerpc64 platforms.
END QUOTE

There may well have been an implicit "from scratch"
intended in that quote. No use of old port builds
either for powerpc64.

Those using binary updates of ports via pkg for
powerpc64 may have mismatch issues around the
transition. I've no clue for binary system updates
(if there are such for powerpc64). (I've only
built from source for world, kernel, and ports
for my normal activity.)



Another issue for those that build from source is
the RAM use and time taken for buildworld buildkernel ,
at least on older or low end hardware, such as old
PowerMacs. The armv7 and small board aarch64 folks
experience with this may prove useful. Avoiding Out
Of Memory process kills from free RAM staying low for
long periods or from slow paging or other issues can
be a challenge. Unfortunately, the messages complain
about being "out of swap" even when that is not the
issue. It is not always clear just what criteria leads
to a OOM process kill, making it hard to figure out
how to avoid those happening.

Real "out of swap" conditions also normally report
console messages of the form:

. . . swap_pager_getswapspace . . .: failed

Otherwise it is unlikely it is actually out of
swap space.

For delaying how long free RAM staying low is
tolerated, one can increase vm.pageout_oom_seq from
12 to larger. The management of slow paging I've
less experience with. With low enough RAM it may
not be possible to have enough swap/page space to
allow llvm materials to all build, even for -j1
builds.

Examples follow that I use in contexts with
sufficient RAM that I do not have to worry about
out of swap/page space for how I buildworld
buildkernel . These I've set in /etc/sysctl.conf .

#
# Delay when persisstent low free RAM leads to
# Out Of Memory killing of processes:
vm.pageout_oom_seq=120
#
# For plunty of swap/paging space (will not
# run out), avoid pageout delays leading to
# Out Of Memory killing of processes:
vm.pfault_oom_attempts=-1

Note: In my context "plunty" really means
sufficient RAM that paging is rare for how
I build. But others have reported on using
the -1 in contexts where paging was heavy
at times and OOM kills had been happening
that were eliminated by the assignment
(more built).

I've no experience with the below alternative
to that -1 use:

#
# For possibly insufficient swap/paging space
# (might run out), increase the pageout delay
# that leads to Out Of Memory killing of
# processes:
#vm.pfault_oom_attempts= ???
#vm.pfault_oom_wait= ???
# (The multiplication is the total but there
# are other potential tradoffs in the factors
# multiplied, even for nearly the same total.)

There are folks that have used the likes
of:

vm.pageout_oom_seq=1200

(but I do not know if such was necessary
for their context.)



I'm not claiming that these 3 vm.??? figures
are always sufficient. Nor am I claiming
that tunables are always available that would
be sufficient. Nor that it is easy to find
the ones that do exist that might help for
specific OOM kill issues.

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