Date: Wed, 18 Jul 2018 12:35:38 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Trev <freebsd-arm@sentry.org> Subject: Re: RPI3 swap experiments Message-ID: <2CFAE691-3176-4E8C-8542-6D66BE4421A6@yahoo.com> In-Reply-To: <20180718190951.GB27481@www.zefox.net> References: <20180629233937.GC35717@www.zefox.net> <0f137e06-214a-3e8c-a216-f061ec04ac2c@sentry.org> <20180630005145.GA43801@www.zefox.net> <6f3406e2-71f3-d0c2-2b65-703e1a1d3c25@sentry.org> <8e92b2b7-da61-3efb-7231-9fac76b2c1d4@sentry.org> <ba33d8a7-a849-3893-8016-0765ebe1c51f@sentry.org> <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <20180704004554.GA61273@www.zefox.net> <20180718060650.GA24566@www.zefox.net> <F31DD1B5-42A8-4A48-A771-D38479604FD5@yahoo.com> <20180718190951.GB27481@www.zefox.net>
index | next in thread | previous in thread | raw e-mail
On 2018-Jul-18, at 12:09 PM, bob prohaska <fbsd at www.zefox.net> wrote: > On Wed, Jul 18, 2018 at 07:42:13AM -0700, Mark Millard wrote: >> >> >> On 2018-Jul-17, at 11:06 PM, bob prohaska <fbsd at www.zefox.net> wrote: >> >>> It appears that some progress has been made in getting swap working reasonably >>> on the RPI3. A -j4 buildworld attempt running r336356 to compile 336431 failed >>> with "out of swap" but the worst read and write delays were less than 5 seconds, >>> a marked improvement over previous examples. >> >> Attributing the time variations that have been observed mostly to FreeBSD and not >> mostly to the device at issue seems to have little or no evidence to support it. >> > Possibly a fair objection. This test is with a USB3.0 flash drive. I'll repeat soon > as possible with a USB3.1 device, which in the past reported much greater (15 second) > delays. > >>> In this case swap was split, 2 each 1GB partitions on USB flash plus 1 GB on the >>> microSD card. Previous attempts using 3 each 1 GB partitions on USB flash have been >>> repeatedly successful, while a single attempt using 3 each 1GB partitions on microSD >>> failed. >> >> The more swap partitions (or space?) not on a /dev/mmcsd0s* the less of the >> activity that /dev/mmcsd0 handles and likely the more time it tends to have >> between explicit operations to do internal housekeeping before the next >> explicit operation. >> >> So the better approximation to not using /dev/mmcsd0 at all might not be >> all that much of a surprise at having less of a problem on the device >> (or a problem less often). >> > In earlier tests (same card type) putting _all_ swap on microSD (along with /tmp) > avoided OOMA kills. Dependable mischief seems to come when swap is on both microSD > and USB. As I do not know what all is going on for Out Of Memory kills, I was only directly talking of the likes of ms/w and/or ms/r time figures being large sometimes. OOMA may have other issues contributing to some of its activity for all I know. Is a difference, for example, 2 GB total swap vs. 3 GB total swap and the message about the swap configuration? The memory tracking swap can fragment and be a source of not being able to use swap as I understand. (I've quoted the man page material in the past in these exchanges.) Large swap spaces can hit such fragmentation issues sooner. (So there is a tradeoff in having more swap than needed as the amount-more increases.) Trev has reported: "I have run the -j4 buildworld now 11 times using a single 2G partition". I wonder what would happen for him if he used two 1 GB partitions or three about 2/3 GB byte partitions. The contrasting case of a working environment changed to have multiple partitions (with the same total) could indicate something about if multiple partitions are sufficient to lead to problems (ms/w, ms/r, OOM killing, or some combination). > It's understood that USB and Ethernet share I/O hardware, but I thought microSD > was at least somewhat independent. Is this wrong? > This I do not know. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2CFAE691-3176-4E8C-8542-6D66BE4421A6>