Date: Sun, 2 Sep 2018 08:27:17 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") Message-ID: <20180902152717.GB44384@www.zefox.net> In-Reply-To: <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> References: <FA3B8541-73E0-4796-B2AB-D55CE40B9654@yahoo.com> <20180814014226.GA50013@www.zefox.net> <CANCZdfqFKY3Woa%2B9pVS5hika_JUAUCxAvLznSS4gaLq2kKoWtQ@mail.gmail.com> <20180815013612.GB51051@www.zefox.net> <CANCZdfoB_AcidFpKT_ZmZWUFnmC4Bw55krK%2BMqEmmj=f9KMQ2Q@mail.gmail.com> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <F3AF3A89-322E-4048-A758-4276C1A1BEA0@yahoo.com> <20180902083217.GA44384@www.zefox.net> <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180902152717.GB44384>