From owner-freebsd-hackers@freebsd.org Sat Jan 13 22:09:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 818BFEB215A for ; Sat, 13 Jan 2018 22:09:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-152.reflexion.net [208.70.210.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F9807A6A6 for ; Sat, 13 Jan 2018 22:09:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23587 invoked from network); 13 Jan 2018 22:02:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Jan 2018 22:02:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 13 Jan 2018 17:02:18 -0500 (EST) Received: (qmail 29175 invoked from network); 13 Jan 2018 22:02:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2018 22:02:18 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5BB56EC9004; Sat, 13 Jan 2018 14:02:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] From: Mark Millard In-Reply-To: Date: Sat, 13 Jan 2018 14:02:16 -0800 Cc: FreeBSD Hackers , Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3CEAAA69-1C79-4545-8ED6-D277A65BBAB1@dsl-only.net> References: <20180113005426.GA48702@www.zefox.net> <5D61DF2C-2CEB-442C-8CBC-1EE0988CF2BC@dsl-only.net> <20180113172731.GB51530@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 22:09:05 -0000 On 2018-Jan-13, at 9:51 AM, Mark Millard wrote: > On 2018-Jan-13, at 9:27 AM, bob prohaska = wrote: >=20 >> On Sat, Jan 13, 2018 at 08:32:20AM -0800, Mark Millard wrote: >>> Does your 2 GiByte swap-space RPi2 "dmesg -a" output >>> (or serial console history) show any messages about the >>> swap-space size and a potential adjustment to a related >>> kernel parameter? >>>=20 >> Yes, console history contains the line >>=20 >> warning: total configured swap (524288 pages) exceeds maximum = recommended amount (405460 pages). >>=20 >> Since top reported what looked like ample swap, and buildworld seemed = to >> run successfully, I didn't heed the >>=20 >> warning: increase kern.maxswzone or reduce amount of swap. >>=20 >> message.=20 >>=20 >> Would it be helpful to do so now? gpart show da0 reports >>=20 >> =3D> 0 122544516 da0 BSD (58G) >> 0 4194304 1 freebsd-ufs (2.0G) >> 4194304 4194304 2 freebsd-swap (2.0G) >> 8388608 6291456 4 freebsd-ufs (3.0G) >> 14680064 107864452 5 freebsd-ufs (51G) >>=20 >> The units are somewhat baffling, since the apparent swap partition >> size does not match (numerically) the dmesg value. >=20 > [gpart is showing in 512 Byte units, probably matching > a drive-organization characteristic.] >=20 > page =3D 4 KiBytes > So 405460 pages =3D 1621840 KiBytes, so a little over 1.54 GiBytes. >=20 > For reference: > 524288 pages =3D 2097152 KiBytes, so exactly 2.0 GiBytes. >=20 > Note: 2*2097152 =3D=3D 4194304 exactly, so the 512 Byte count > is an exact match to the 2.0 GiByte swap size. >=20 > When there is only 1 GiByte of RAM, I'm not sure if increasing > kern.maxswzone is a good tradeoff or not. >=20 > Historically I've kept the swap space within the recommended > maximum for the default kern.maxswzone value. But for the RPi2B > V1.1 context, I've not tried a self-hosted buildworld in a > long time, doing cross builds instead. On a RPi2B V1.1 I get: db> print *maxswzone 0 The code in swap_pager_swap_init has : /* * Initialize our zone, guessing on the number we need based * on the number of pages in the system. */ n =3D vm_cnt.v_page_count / 2; if (maxswzone && n > maxswzone / sizeof(struct swblk)) n =3D maxswzone / sizeof(struct swblk); which means that maxswzone is ignored because it is zero and vm_cnt.v_page_count / 2 is used directly. Setting maxswzone can not make n any larger, only smaller. it would appear that "increase kern.maxswzone" only applies when one already has set the figure manually in a manor that restricts n. Quoting "man 8 loader" : 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. Multiple points relative to the above: Note that "care should be taken to not configure more swap than = approximately half of the theoretical maximum" because "swap metadata can be = fragmented" and "the system can run out of space before it reaches the theoretical = limit". Looking at the swapon_check_swzone code the message is reporting the "half" figure, not the theoretical maximum. But there is also: 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. If I read all this right, it says that reducing swap is normally the intended handling when the message is reported unless one has been adjusting various kernel resource reservations. That would be consistent with the maxswzone only being able to decrease n in the code that I quoted earlier. Given that 1 GiByte of RAM and 2 GiByte of Swap reports that the maximum recommended swap is about 1.54 GiBytes (converting from pages), the: 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. just seems to not apply directly to an RPi2B V1.1: 1.54 is much less = than 8*1. =3D=3D=3D Mark Millard markmi at dsl-only.net