Date: Sat, 13 Jan 2018 14:02:16 -0800 From: Mark Millard <markmi@dsl-only.net> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] Message-ID: <3CEAAA69-1C79-4545-8ED6-D277A65BBAB1@dsl-only.net> In-Reply-To: <A11A2BF4-13FB-4587-8695-B07FC12692EE@dsl-only.net> References: <20180113005426.GA48702@www.zefox.net> <5D61DF2C-2CEB-442C-8CBC-1EE0988CF2BC@dsl-only.net> <20180113172731.GB51530@www.zefox.net> <A11A2BF4-13FB-4587-8695-B07FC12692EE@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Jan-13, at 9:51 AM, Mark Millard <markmi@dsl-only.net> wrote:
> On 2018-Jan-13, at 9:27 AM, bob prohaska <fbsd at www.zefox.net> =
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CEAAA69-1C79-4545-8ED6-D277A65BBAB1>