Date: Fri, 27 Dec 2019 03:53:37 -0800 From: Mark Millard <marklmi@yahoo.com> To: svn-src-head@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: svn commit: r356116 - head (powerpc families jumping to clang-based; powerpc64 also to ELFv2) Message-ID: <C044FA69-556E-4A0F-AFDB-1FDE94407147@yahoo.com> References: <C044FA69-556E-4A0F-AFDB-1FDE94407147.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C044FA69-556E-4A0F-AFDB-1FDE94407147>