From owner-freebsd-arm@freebsd.org Tue Jan 8 09:54:05 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E1281499287 for ; Tue, 8 Jan 2019 09:54:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E02E4821D4 for ; Tue, 8 Jan 2019 09:54:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Wr0Z1wAVM1lIOwbZm6W8MbvvAAPBoakPaK0n5NES.t3E.zLuAVR.5aFkOCp5hOZ WLB7BXqlP1W_SiKNXnC7XNyynDKOrXMzEO1r7KZ._bzoN_U5PMCOGOJImzy3Q1YiOR6vX7028QcR 6.lvE3reTeGrbspy4pzg01Y0l0Q7Bnn1X38144nuJOcG472eRzOyDEyPZyFw3IhSq7In3ZUA7.Kp bNh_cdZ64yo2Vkk1QBsVazBCYe0oGOLvBYI8Gm.vlEJiOXjZgKgTu.sBdAr4DB0bOGZa3Bla9aa1 .RT_ycm5o2Ldp00JdwsZHsSPQ4ylaGGyvYIEzPEUpqorGicJQdkVC.oMM3x9IORnzlNDgVpx2yP3 JrOJNUjmhA9ezeevDWJPDdXlTDZfm_zz3K2pw.bq5WMcvPKifAxwAcqhiyzMSEd9Z0Ei9DTZ0yj4 3tjnD8bUtQ8jV.cNjFjQQ38L.8uXqoacc67wiBZ5iuv1PqlhichKqVrMGkvHaOor0xYgDbvXXPL1 fze_YpyEOmcvcVga1xYc1vVebOQ.3JxIWWGBC_g_KBlE28ELzQbt3nVHfK.HmNGLB5v_kwbXOJ_W DpF4VLIgAgtv4ZP74qvs2x1gL2vRRw3bncL1WVO3jffNbmdIJIaxe7m6iPUVnu8dR7WcudgVPwD0 3qzv10H5eD5mP6CN0UM5rSry18Tf2okE1.P4XJIieUOmTRj6ZVZxeUskKup.mAEEaWk3s.Xm0EVD PzMr.1Briyi6EAiiTVdLUPQUbwMPnQEPji.7X4PGd6d3fHFFoUNq2W.hM5nJjRDj9gjuXbJ5GiaB YhANeWgDS7ZonRN0_10UOvoyc3c9nyx9tPNMnk1TVja0izYKeLGRcy8m0_4bMQVz7Ym.ysiXg6T9 tH3WJYAzfsDoRhPAffDb6CcW5G4ukj.K7nuK1FBTobnNzOeH66NDlE61ikfX7.8B12mMoO2FuSfd CvNclM9gDfkM4xTZ3d3qqMgwwVmyzRmxWUAaMhTqOtknPU3yrQk4zBnwFqSUfYvjraOuDKt0GFU0 CVdlq7SRM5sGNAWKO8QgsNCaqvMPii6x31KiDvPN1nDWAmrDfbOL8x5uKagrZuwUBEZ4U0x1CENb ZdJwX.9Hk Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Jan 2019 09:53:56 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp407.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f9c4ba79d08a3f5c6dc9db3857706e16; Tue, 08 Jan 2019 09:53:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: make buildworld error while compiling 12.0-releng for RPI2 From: Mark Millard In-Reply-To: <20190107214116.GB30472@cicely7.cicely.de> Date: Tue, 8 Jan 2019 01:53:52 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <67DDC863-63C5-451F-ACFC-336A3304EF4D@yahoo.com> References: <897D5769-58A0-4349-9FA4-1C4551F3A5A6@gmail.com> <290CC356-180C-405C-B1D1-1CD5F96BA905@gmail.com> <20190107214116.GB30472@cicely7.cicely.de> To: ticso@cicely.de, Victor X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: E02E4821D4 X-Spamd-Bar: / X-Spamd-Result: default: False [0.75 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.835,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.92)[0.920,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.03)[ip: (4.15), ipnet: 98.137.64.0/21(0.59), asn: 36647(0.47), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.15)[0.149,0]; RCVD_IN_DNSWL_NONE(0.00)[82.68.137.98.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 09:54:05 -0000 On 2019-Jan-7, at 13:41, Bernd Walter = wrote: > On Mon, Jan 07, 2019 at 02:59:22PM +0100, Victor wrote: >> Thank you, Ralf. >> As a matter of fact I issued=20 >>=20 >> make buildword >>=20 >> NOT=20 >>=20 >> make -j4 buildworld >>=20 >> The compilation problem is still there. >=20 > Anyways - this is an out of memory problem. > dmesg will show you why the process was killed. > You have to add more swap space. > Unfortunately compilers get more and more CPU and memory hungry. > These days I use memory sticks capable of high random load as = temporarys > swap space or NFS space - later mostly for obj and src, not as swap so = much. > For me SanDisk Extreme Go 3.1 and Ultra USB 3.0 worked great. > That said, I havn't build FreeBSD12 on any ARM myself yet and this is > only a general experience. >=20 I'm just adding some notes about interpreting the console/dmesg = messages, as one of them is misleading (a misnomer) --plus other related notes. There was a prolonged list exchange and investigation of buildworld on rpi2's and rpi3's during 2018, ending in 2018-Sept. The below was learned during that. If one is really out of swap space there should be messages like: Aug 5 17:54:01 sentinel kernel: swap_pager_getswapspace(32): failed But if one does not see such messages yet does see messages like: Oct 30 05:15:31 xindi kernel: pid 68935 (rustc), uid 65534, was killed:=20= out of swap space then one is likely not actually out of swap space and adding swap space will likely not prevent the process kills. Unfortunately, the wording of that last message is a misnomer for what drives the kills: it is actually driven by being unable to gain more free memory but FreeBSD will not swap-out processes that stay runnable (or are running), only ones that are waiting. Even a single process that stays runnable and keeps lots of RAM in the active category can lead to kills when swap is unused or little used. So the kill-behavior is very workload dependent. If only the later type of message is showing up, having something like: # more /etc/sysctl.conf=20 vm.pageout_oom_seq=3D120 with a figure bigger than the default 12, possibly even something like 1024 or 2048 or even more may delay the kills long enough to avoid the kills because the processes in question then completes first. (The units are not time but a count, but larger counts take more time before the process kills start.) By contrast, if you are seeing the swap_pager_getswapspace messages, you have to add swap space. There is kern.maxswzone figure that is = associated with swap size and with possible warning pairs when swap space is added, for example: warning: total configured swap (524288 pages) exceeds maximum = recommended amount (405460 pages). warning: increase kern.maxswzone or reduce amount of swap. (An rpi2 V1.1 (armv7) and an rpi3 (aarch64) with the same amount of RAM get rather different figures at the right.) There was in stable/12 -r341716 : MFC r341375 : Allow to create swap zone larger than v_page_count / 2. and in stable/11 -r341718 : MFC r341375 : Allow to create swap zone larger than v_page_count / 2. (So release/12.0.0 or release/11.2.0 do not allow such an increase.) There is is a kernel memory tradeoff structure to increase in kern.maxswzone being larger as I understand. Quoting "man 8 loader" (but the "eight times" is system/architecture specific and will likely be different): kern.maxswzone Limits the amount of KVM to be used to hold swap = metadata, which directly governs the maximum amount of swap the system can support, at the rate of approximately 200 = MB of swap space per 1 MB of metadata. This value is = specified in bytes of KVA space. If no value is provided, the = system allocates enough memory to handle an amount of swap = that corresponds to eight times the amount of physical = memory present in the system. Note that swap metadata can be fragmented, which means = that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken to = not configure more swap than approximately half of the theoretical maximum. Running out of space for swap metadata can leave the = system in an unrecoverable state. Therefore, you should only change this parameter if you need to greatly extend = the KVM reservation for other resources such as the buffer = cache or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX. I also use (not just on small arm hardware): LDFLAGS.lld+=3D -Wl,--no-threads in my equivalents of /etc/make.conf . This avoids lld creating N+2 = threads, N being the the cpu count as FreeBSD counts cpus. This also seems to cut down on memory use during links. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)