Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top]

[Mark Millard]

On 2018-Jan-13, at 9:51 AM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2018-Jan-13, at 9:27 AM, bob prohaska <fbsd at www.zefox.net> wrote:
> 
>> 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?
>>> 
>> Yes, console history contains the line
>> 
>> warning: total configured swap (524288 pages) exceeds maximum recommended amount (405460 pages).
>> 
>> Since top reported what looked like ample swap, and buildworld seemed to
>> run successfully, I didn't heed the
>> 
>> warning: increase kern.maxswzone or reduce amount of swap.
>> 
>> message. 
>> 
>> Would it be helpful to do so now? gpart show da0 reports
>> 
>> =>        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)
>> 
>> The units are somewhat baffling, since the apparent swap partition
>> size does not match (numerically) the dmesg value.
> 
> [gpart is showing in 512 Byte units, probably matching
> a drive-organization characteristic.]
> 
> page = 4 KiBytes
> So 405460 pages = 1621840 KiBytes, so a little over 1.54 GiBytes.
> 
> For reference:
> 524288 pages = 2097152 KiBytes, so exactly 2.0 GiBytes.
> 
> Note: 2*2097152 == 4194304 exactly, so the 512 Byte count
> is an exact match to the 2.0 GiByte swap size.
> 
> When there is only 1 GiByte of RAM, I'm not sure if increasing
> kern.maxswzone is a good tradeoff or not.
> 
> 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 = vm_cnt.v_page_count / 2;
        if (maxswzone && n > maxswzone / sizeof(struct swblk))
                n = 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.


===
Mark Millard
markmi at dsl-only.net