RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024")

bob prohaska fbsd at www.zefox.net
Sun Sep 2 15:27:00 UTC 2018


On Sun, Sep 02, 2018 at 06:57:15AM -0700, Mark Millard wrote:
> Was this with or without (presuming a ufs file system):
> 
> tunefs: trim: (-t)                                         enabled
> 
> ? If enabled, with or without:
> 
> sysctl vfs.ffs.dotrimcons=1
> 
> In other words: was "consolidation of TRIM / BIO_DELETE
> commands to the UFS/FFS filesystem" enabled? Disabled?
> 

No, it was not. By all accounts TRIM enabling won't affect USB2.0 devices,
and it's fairly clear the bottleneck is in USB, not microSD. Trim is enabled
for mmcsd0s2a, but sysctl vfs.ffs.dotrimcons=1 hasn't been invoked. I'll turn
it on later, to check for bad side effects, but there's no obvious reason to
think it'll help.

At the moment the diskscript is reporting:

dT: 10.005s  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      0    0.0      0      9    5.2      0      0    0.0    0.2  mmcsd0
   10      0      0      0    0.0      0      2  13790      0      0    0.0   89.9  da0
    0      0      0      0    0.0      0      2    3.9      0      0    0.0    0.1  mmcsd0s2b
    0      0      0      0    0.0      0      9    5.2      0      0    0.0    0.2  mmcsd0s2
    9      0      0      0    0.0      0      2  13790      0      0    0.0   89.9  da0b
Sun Sep  2 08:17:14 PDT 2018
Device          1K-blocks     Used    Avail Capacity
/dev/da0b         1048576   494352   554224    47%
/dev/mmcsd0s2b    1048576   478860   569716    46%
Total             2097152   973212  1123940    46%
Sep  2 08:14:38 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1649558, size: 4096
Sep  2 08:14:38 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1654590, size: 16384

Top is reporting ~10-50% idle time, not surprising given delays writing to da0b. 
I was hoping the pager might favor microSD given the much faster I/O times,
but evidently not. Seems to be a strict round-robin division of labor.

Thanks for reading!

bob prohaska
 


More information about the freebsd-arm mailing list