RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"]

[Mark Millard]

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 at freebsd.org> wrote:
>> . . .
>> gstat tends to show things such as:
>> 
>> 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
>> 
>> 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.)
> 
> 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.
> 
> 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 = 7985.6 ms  = 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.





===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)