Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jul 2018 16:24:53 -0700
From:      bob prohaska <fbsd@www.zefox.net>
To:        freebsd-arm@freebsd.org
Subject:   Re: RPI3 swap experiments
Message-ID:  <20180725232453.GA57716@www.zefox.net>
In-Reply-To: <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com>
References:  <8e92b2b7-da61-3efb-7231-9fac76b2c1d4@sentry.org> <ba33d8a7-a849-3893-8016-0765ebe1c51f@sentry.org> <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <bc8da02c-4465-9634-6fd0-0af4c63aa49d@sentry.org> <20180723063526.GA45726@www.zefox.net> <AB5EE2E4-B2FD-4CA9-A993-04C2A4BE10AE@yahoo.com> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Made another pass at using mixed (microSD plus USB) swap to run a -j4 buildworld on
r336704. As expected, it stopped with
13:18:50 www kernel: pid 94472 (c++), uid 0, was killed: out of swap space

However, the longest write delay recorded happened much earlier and didn't seem
to route OOMA's ire at all:
dT: 10.039s  w: 10.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps   ms/d   %busy Name
    0      0      0      3    5.1      0      3    5.6      0      0    0.0    0.1  mmcsd0
   49      1      0      0    0.0      1     13  35716      0      0    0.0  104.7  da0
    0      0      0      3    5.2      0      3    5.6      0      0    0.0    0.1  mmcsd0s2
    0      0      0      3    5.2      0      3    5.7      0      0    0.0    0.1  ufs/rootfs
   40      1      0      0    0.0      1     13  34915      0      0    0.0  104.7  da0d
Wed Jul 25 12:44:37 PDT 2018
Device          1K-blocks     Used    Avail Capacity
/dev/mmcsd0s3b    1048576     7272  1041304     1%
/dev/da0b         1048576     7028  1041548     1%
Total             2097152    14300  2082852     1%

The machine ran normally for about half an hour after the worst-case write delay, before
OOMA caught on (to something) and reacted.

The worst read delay happens even earlier:
dT: 10.002s  w: 10.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps   ms/d   %busy Name
    0     30      0      0    0.0     30    571    3.1      0      0    0.0    9.0  mmcsd0
    0     45      0      0  27403     45    484   8631      0      0    0.0   70.8  da0
    0     30      0      0    0.0     30    571    3.1      0      0    0.0    9.2  mmcsd0s3
    0     30      0      0    0.0     30    571    3.2      0      0    0.0    9.2  mmcsd0s3a
    0      0      0      0  27403      0      0    0.0      0      0    0.0  274.0  da0a
    0     45      0      0    0.0     45    484   8631      0      0    0.0   70.8  da0d
Wed Jul 25 10:15:31 PDT 2018
Device          1K-blocks     Used    Avail Capacity
/dev/mmcsd0s3b    1048576     4384  1044192     0%
/dev/da0b         1048576     4292  1044284     0%
Total             2097152     8676  2088476     0%
Jul 25 08:54:18 www su[1420]: bob to root on /dev/pts/0
Jul 25 09:32:26 www sshd[28651]: error: maximum authentication attempts exceeded for invalid user admin from 1.171.181.193 port 43216 ssh2 [preauth]

even earlier in buildworld, with likewise no disturbing effect.

Is it even possible for slow storage speeds to account for the OOMA kills? It looks as if
the swap partitions aren't particularly busy at the time.

Thanks for reading,

bob prohaska


 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180725232453.GA57716>