Date: Mon, 18 Jun 2018 22:27:39 -0600 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: GPT vs MBR for swap devices Message-ID: <CANCZdfoBurbe98dYC6nqBX8JXnkjcQX-KAmLQUApwmMkgsQc9A@mail.gmail.com> In-Reply-To: <127A4F5A-086E-4825-81B8-89BC95677F0E@yahoo.com> 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> <127A4F5A-086E-4825-81B8-89BC95677F0E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 18, 2018, 10:15 PM Mark Millard via freebsd-arm < freebsd-arm@freebsd.org> wrote: > > > 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: > >> > >> . . . > >> I see a ms/w (and ms/r) that is fairly large (but notably > >> smaller than the ms/w of over 12000): > >> > >> 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% > >> > >> > > 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 > > I'll get rid of the ten second sleep in the script when the present test > run > > finishes. > > > > 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. > Yes partitioning is a logical thing. You never know for sure what is taking a long time or the cause. All you can see is the effect. 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.) > Usually with usb flash it does. SSDs have multiple channels to the NAND. USB often does not... 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.) > Large latencies usually means slow page cleaning. No page cleaning means OOM. Warner > >> . . > >> 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.) > >> > > 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. > > Which suggests an experiment: use 1 GB SD swap and 1.3 GB mechanical > > USB swap. That's easy to try. > > 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. > > > > 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, > > 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. > >> > > > > 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. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoBurbe98dYC6nqBX8JXnkjcQX-KAmLQUApwmMkgsQc9A>