Date: Mon, 20 Aug 2018 08:57:26 -0700 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.com> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-arm <freebsd-arm@freebsd.org>, Mark Johnston <markj@freebsd.org> Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <6CF1F2FD-104E-4296-AB9C-74009C3ACA4B@yahoo.com> In-Reply-To: <CANCZdfroR72T_9Omo0bAoWLs9JsTPvJ4xnYrqabSgUuX-Pe7qg@mail.gmail.com> References: <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <B81E53A9-459E-4489-883B-24175B87D049@yahoo.com> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180815221728.GA59074@www.zefox.net> <9EA5D75D-A03F-4B25-B65E-03E93DE30130@yahoo.com> <BD92A3B6-BCD2-4FA5-A9C6-0B950D3AD378@yahoo.com> <CANCZdfroR72T_9Omo0bAoWLs9JsTPvJ4xnYrqabSgUuX-Pe7qg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Aug-20, at 7:59 AM, Warner Losh <imp at bsdimp.com> wrote: > On Mon, Aug 20, 2018 at 8:00 AM, Mark Millard via freebsd-arm = <freebsd-arm@freebsd.org> wrote: >> . . . >> gstat tends to show things such as: >>=20 >> dT: 1.006s w: 1.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 0 0.0 0 0 0.0 0 0 = 0.0 0.0| mmcsd0 >> 56 312 0 0 0.0 312 19985 142.6 0 0 = 0.0 99.6| da0 >>=20 >> where the ms/w and kBps are fairly stable but the Length >> of the queue length is widely variable. For the above it >> makes the likes of 56 writes queued * 142.6 ms/write (mean) >> [as an estimate] a rather large total time for the last >> of the queued writes to complete. (If I understand how >> to interpret the above.) >=20 > No. 142.6ms/write is the average of the time that the operations that = completed during the polling interval took to complete. There's no = estimating here. >=20 > So, at 6 or 7 per second for the operation to complete, coupled with a = parallel factor of 1 (typical for low end junk flash), we wind up with = 56 operations in the queue taking 8-10s to complete. 56 * 142.6 ms/w =3D 7985.6 ms =3D 7.985.6 s, near the low end of your = range. I do not see how my proposed multiplication is inappropriate as an = estimate of your range. I do not know that gstat gets the 56 and the 142.6 ms/w from the exact = same time frame/context. (It might well for all I know.) So I did not want to claim too much. > . . . > These numbers are consistent with the theory that the swap device = becomes overwhelmed, spiking latency and causing crappy down-stream = effects. If over the whole test gstat -pd never shows more than, say, 200 ms/w for its about 1 second intervals, how can there be large spiking of latency to beyond, say, 1 second? I supposed that if the USB device has multiple writes active at once and some complete quickly but others do not, then such could be the case. But this would not be "parallel factor of 1 (typical for low end junk flash)". For the below, I realize that the device is in use in a USB 2.0 environment, which means 3.0 specific features would not be in use. Still, it gives some context about the device. The USB device is USB 3.0 capable that can sustain around 400 MiByte/sec sequential writes when connected to a USB 3.0 capable connection. I even over-provisioned it by leaving a free-space partition. I think the controller might be a Silicon Motion SM2258XT flash controller and Asmedia 1153e for USB. I've had the device for some time but I looked up the current "specs" for the brand/model it was sold under. I can not claim things were the same back then. The specs indicate UASP compliant, NCQ support, as well as S.M.A.R.T support. As I remember that was true back then as well. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6CF1F2FD-104E-4296-AB9C-74009C3ACA4B>