Date: Mon, 18 Jun 2018 21:14:48 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: GPT vs MBR for swap devices Message-ID: <127A4F5A-086E-4825-81B8-89BC95677F0E@yahoo.com> In-Reply-To: <20180619034232.GA81800@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <A8D00616-ADA7-4A33-8787-637AFEF547CF@yahoo.com> <20180619005519.GB81275@www.zefox.net> <BC42DDF9-9383-437B-8AE2-A538050C5160@yahoo.com> <20180619034232.GA81800@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Jun-18, at 8:42 PM, bob prohaska <fbsd at www.zefox.net> wrote: > On Mon, Jun 18, 2018 at 06:31:40PM -0700, Mark Millard wrote: >> On 2018-Jun-18, at 5:55 PM, bob prohaska <fbsd at www.zefox.net> = wrote: >>=20 >> . . . >> I see a ms/w (and ms/r) that is fairly large (but notably >> smaller than the ms/w of over 12000): >>=20 >> Mon Jun 18 13:12:58 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 0 1048576 0% >> dT: 10.400s 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 4 0 0 0.0 4 66 3.4 0 0 = 0.0 1.3 mmcsd0 >> 8 18 1 32 1991 17 938 2529 0 0 = 0.0 88.1 da0 >> 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3 >> 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3a >> 6 11 1 32 1991 10 938 3207 0 0 = 0.0 94.7 da0d >> Mon Jun 18 13:13:19 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 0 1048576 0% >>=20 >>=20 > Yes, but again, it's on /usr, not swap. One could argue that there = are other > write delays, not seen here, that do affect swap. To forestall that = objection=20 > I'll get rid of the ten second sleep in the script when the present = test run > finishes.=20 >=20 If the drive /dev/da0 has any partitions with large ms/w (or ms/r) figures sometimes, all partitions on the drive are likely subject to the same if /dev/da0 is a flash or SSD drive. At least that is my understanding. Also if /dev/da0 has any partition with an active I/O that takes a long time, it may well block I/O on any other partition on the same drive until it completes. (As far as I know for a USB flash and FreeBSD. I'm no expert at such issues.) My suggestions have been trying to see if eliminating all the large ms/w (and ms/r) on the drive(s) used for swap makes the problem go away, not just on the swap partitions. If FreeBSD might have more overall cross-device "large ms/w" interference was also something I was trying to avoid having any chance of being involved. (I've no clue if such has a chance of being an issue.) >> . .=20 >> Can you get a failure without involving da0, the drive that is >> sometimes showing these huge ms/w (and ms/r) figures? (This question >> presumes having sufficient swap space, so, say, 1.5 GiByte or more >> total.) >>=20 > If you mean not using da0, no; it holds /usr. If you mean not swapping > to da0, yes it's been done. Having 3 GB swap on microSD works.=20 > Which suggests an experiment: use 1 GB SD swap and 1.3 GB mechanical > USB swap. That's easy to try.=20 For what I was thinking of testing you would have to have /usr and the rest being on some other drive than one that gets the large ms/w (and/or ms/r) figures: you would need to avoid that drive because all partitions on that drive are likely subject to the large ms/w (and ms/r) figures. Avoiding swap being on any partition of /dev/da0 is a less extreme form of isolating things. >> Having the partition(s) each be sufficiently sized but for which >> the total would not produce the notice for too large of a swap >> space was my original "additional" suggestion. I still want to >> see what such does as a variation of a failing context.=20 >=20 > I'm afraid you've lost me here. With two partitions, one USB and > the other SD of one GB each OOM kills happen at 8% utilization,=20 > spread evenly across both. Does the size of the partition affect > the speed of it? Capacity does not seem the problem. Being able to just turn off one of two partitions allows testing if it is having more than one that makes the difference if OOM killing of processes happens. (Similarly exchanging which is off.) But only if each is large enough to allow the run to complete. Not that such is the actual issue or likely, but imagine that some test for OOM process killing was using the size of the smallest active swap partition to test if OOM was needed instead of testing the total. (The log files are just sampling and are unlikely to show peak swap space "used" figures.) >> it would seem to be a good idea to avoid da0 and its sometimes >> large ms/w and /ms/r figures. >>=20 >=20 > I think the next experiment will be to use 1 GB of SD swap and > 1.3 GB of mechanical USB swap. We know the SD swap is fast enough, > and we know the USB mechanical swap is fast enough. If that > combination works, maybe the trouble is congestion on da0. If the = combo > fails as before I'll be tempted to think it's USB or the swapper. Sounds like a plan if large ms/w (and ms/r) figures for /dev/da0 can not interfere with other drives. =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?127A4F5A-086E-4825-81B8-89BC95677F0E>