Date: Tue, 31 Jul 2018 00:02:12 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPI3 swap experiments Message-ID: <9FC91439-383B-4A01-ACF4-7CAF36BC9747@yahoo.com> In-Reply-To: <50802D52-9CB2-4E55-A80D-6E8D68B81431@yahoo.com> References: <ba33d8a7-a849-3893-8016-0765ebe1c51f@sentry.org> <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <bc8da02c-4465-9634-6fd0-0af4c63aa49d@sentry.org> <20180723063526.GA45726@www.zefox.net> <AB5EE2E4-B2FD-4CA9-A993-04C2A4BE10AE@yahoo.com> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> <50802D52-9CB2-4E55-A80D-6E8D68B81431@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Jul-30, at 11:44 PM, Mark Millard <marklmi at yahoo.com> wrote: > On 2018-Jul-30, at 10:47 PM, bob prohaska <fbsd at www.zefox.net> = wrote: >=20 >> OOMA is still killing processes in -j4 buildworld sessions for no = obvious reason >> when using mixed USB/microSD swap. The most recent experiment is = with r336877=20 >> rebuilding itself from a clean start. >>=20 >> The various log files are at=20 >> http://www.zefox.net/~fbsd/rpi3/swaptests/r336877/ >> The OOMA kills occur around two hours after >> the worst read/write delays, which are in the low tens >> of seconds. Perhaps most curiously, the long delays >> don't appear to involve swap partitions.=20 >>=20 >> Similar problems now seem present with the RPI2 on >> 11-stable. The first failure was with r335398 trying=20 >> to compile 336871. Buildworld has been backed down to=20 >> -j2 and restarted in the hope it'll eventually succeed. >> In this particular case all swap is on USB, in a single >> 2 GB partition. >=20 > My records indicate (from old boot messages and reported > in past list messages): >=20 > rpi2: . . . exceeds maximum recommended amount (411488 pages). > rpi3: . . . exceeds maximum recommended amount (925680 pages). >=20 > 411488*4K Bytes =3D 1,685,454,848 Bytes for rpi2 (older V1.1 armv7 > variant). In other words: you have more swap than is recommended > for such a context because of fragmentation issues and such for > overhead information related to keeping track of swapping/paging. >=20 > I suggest trying not exceeding the 1,685,454,848 figure for the > rpi2 context, just as a cross check. May be 411000*4K Bytes, > so 1,683,456,000 Bytes, avoiding being right at the boundary? >=20 > 925680*4K Bytes =3D 3,791,585,280 Bytes for rpi3. >=20 > Are thew drives involved different ones than used with the > rpi3 experiments? (Just curious.) >=20 >=20 >> It would be most interesting to see what happens if OOMA >> could be turned off. Is that possible?=20 >=20 > If the code reaches conditions which initiate OOMA now, what > would proposed alternate action be? As stands if OOMA itself > fails to happen, my guess would be the kernel would panic, > deadlock, or livelock in some way. Simply having OOMA not > attempted would likely be the same as OOMA failing unless > more than disabling OOMA was done. >=20 > (I'm no expert at such so if someone that knows makes a claim, > believe them instead of me.) Looking around, there have been other rpi2 figures that I've seen and reported on the lists, for example: exceeds maximum recommended amount (405460 pages) exceeds maximum recommended amount (469280 pages) So if you do not have a specific figure from a boot message, your might want: 400000*4K Bytes =3D 1,638,400,000 Bytes or even somewhat less. If you have a specific figure from a current boot message for the same version, I'd go somewhat less than that figure scaled to Bytes. =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?9FC91439-383B-4A01-ACF4-7CAF36BC9747>