Date: Sun, 4 Mar 2018 13:03:12 -0700 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi26-fbsd@yahoo.com> Cc: Freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Is maximum swap usage tunable? Message-ID: <CANCZdfrcJ4SjEerA_N2eEnZ82zn_ePXF5y%2BVzKo5C5cdhD18Sg@mail.gmail.com> In-Reply-To: <1EB91943-C141-4EA6-AD63-A629525E206E@yahoo.com> References: <1EB91943-C141-4EA6-AD63-A629525E206E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 4, 2018 at 12:51 PM, Mark Millard via freebsd-arm < freebsd-arm@freebsd.org> wrote: > bob prohaska fbsd at www.zefox.net write on > Sun Mar 4 18:28:36 UTC 2018: > > > The worst-case events were > > dT: 10.002s w: 10.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > > . . . > > 0 1 0 13 5.6 1 28 5674 88.3 da0b > > . . . > > I'll note that (1000s/ms)*(ms/w) != 1/(w/s) here > (and frequently). (ms/r and r/s are similarly related.) > > It appears that ms/w counts time with the write > waiting in a queue to be executed or some such but > w/s is strictly the observed rate of writes happening, > independent of how long each waited. (The columns need > not refer to the exact same time frame either as far > as I can tell.) > > [Someone may know the actual details of what ms/w > and ms/r spans. The above includes guess work.] > ms/w is the average time each write, that completed in the polling interval, took to complete after being submitted to the block layer. This includes both software queueing time, if any, and hardware transaction time (including interrupt latency). It's an all-in number. The w/s number is the number of writes completed in the polling interval, divided by the polling interval. > Also: 5674 ms/w is over 5 seconds "per write" (probably > a "mean" form of average, but possibly only one write > covered). I doubt that we can be sure of much about the > stages involved in that large figure if "time waiting > in the queue" and later stages of the processing all > contribute. It means that during the polling interval, the average time of the transactions ending in the polling interval, took 5.6s to complete. Even with mad-queueing, that's about 10x-100x the latency one should normally expect. But it doesn't really matter, for these purposes, if it took 5s to complete 1 I/O, or if it was in the queue for 4.9s and then took .1s to complete. It's still really long and stretching the bounds of what the system can put up with. The write-link to the device is hyper-saturated and no good, and likely some bad, will come from that. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrcJ4SjEerA_N2eEnZ82zn_ePXF5y%2BVzKo5C5cdhD18Sg>