Date: Mon, 4 Mar 2013 07:35:47 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Don Lewis <truckman@FreeBSD.org> Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <20130304053547.GY2930@kib.kiev.ua> In-Reply-To: <201303040301.r2431Rjm008175@gw.catspoiler.org> References: <52867.1362317749@critter.freebsd.dk> <201303040301.r2431Rjm008175@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--L4xCDQ7GT+ph8Lmk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 03, 2013 at 07:01:27PM -0800, Don Lewis wrote: > On 3 Mar, Poul-Henning Kamp wrote: >=20 > > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > > traffic to other disks too, when these pileups gets too bad. >=20 > The Lemming-syncer problem should have mostly been fixed by 231160 in > head (231952 in stable/9 and 231967 in stable/8) a little over a year > ago. The exceptions are atime updates, mmaped files with dirty pages, > and quotas. Under certain workloads I still notice periodic bursts of > seek noise. After thinking about it for a bit, I suspect that it could > be atime updates, but I haven't tried to confirm that. I never got a definition what a Lemming syncer term means. The (current) syncer model is to iterate over the list of the active vnodes, i.e. vnodes for which an open file exists, or a mapping is established, and initiate the neccessary writes. The iterations over the active list is performed several times during the same sync run over the filesystem, this is considered acceptable. (Mostly) independently, the syncer thread iterates over the list of the dirty buffers and writes them. The "wdrain" wait is independend from the syncer model used. It is entered by a thread which intends to write in some future, but the wait is performed before the entry into VFS is performed, in particular, before any VFS resources are acquired. The wait sleeps when the total amount of the buffer space for which the writes are active (runningbufspace counter) exceeds the hirunningbufspace threshold. This way buffer cache tries to avoid creating too long queue of the write requests. If there is some device which has high latency with the write completion, then it is easy to see that, for the load which creates intensive queue of writes to the said device, regardless of amount of writes to other devices, runningbufspace quickly gets populated with the buffers targeted to the slow device. Then, the "wdrain" wait mechanism kicks in, slowing all writers until the queue is processed. It could be argued that the current typical value of 16MB for the hirunningbufspace is too low, but experiments with increasing it did not provided any measureable change in the throughput or latency for some loads. And, just to wrestle with the misinformation, the unmapped buffer work has nothing to do with either syncer or runningbufspace. >=20 > When using TCQ or NCQ, perhaps we should limit the number of outstanding > writes per device to leave some slots open for reads. We should > probably also prioritize reads over writes unless we are under memory > pressure. Reads are allowed to start even when the runningbufspace is overflown. --L4xCDQ7GT+ph8Lmk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRNDKyAAoJEJDCuSvBvK1BWqwQAJF7jUjb3dPjdxakgYS1fm2y Zx4KsWcq7+UOx6HYrmNms5NBXD/zpj/o4wFQrZ3R0UJBhAlmNJkdvXP149TnNRjc ufb6aLKQU+UikcKK1gExJ96R3/JiBPRYcvCcSRWEcp+F8Q2cRzHDh+g8FdJGCE7l J6+skc4GfacEzzIthzBJTHPq/AfdPzxNcr5zktPJskNvi9E6EJsw07AeWF3nB0so eysCKcYxJYxrFkQHuzAaEIvUlUtuUlioK9Xhj5fAOsbtV/3pua0q7cdQq4jcm8hT 1hcY1eXl3D+PloPoaTz4GVqNUn5LQ0a4YR05HGx7zF6dHQVm0JomdvOAIApqSpDP G7XFHhz7nV3KNPdFfaNuXrfeOY7HMGy8jZpq+WGmltnfR8KxjcwtgMJuRuR7yGdq WPscdno8YD9AP3JoAKQvy0Z6LM65ygitEA8zB+R+iVLFA3P6LAhYMLRhFjBHGobL A36EF1O/C55pv9X3bj6XK2jf/HjJHMAmrmTsxEgGcLlBNLO+EgLZYWgIjj8qGWoT 38evTjYethL3dQj8KN66Xw+OBVQMJXKSCV0vv7eOHMbLpcGk5hSRJd/EASyOAYYr XzFR2MsApAd7x/Hx4cGBXXQLyfyIZ0S6qbwXibDdYb6423cwp+68xbOaJqJsJABq KrZQpWI3jGvX0cyqI6nT =1C5w -----END PGP SIGNATURE----- --L4xCDQ7GT+ph8Lmk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130304053547.GY2930>