On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote: > On 3 Mar, Poul-Henning Kamp wrote: > > > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > > traffic to other disks too, when these pileups gets too bad. > > 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. > > 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. > Then either those changes didn't have the intended effect, or the problem we're seeing with lack of system responsiveness when there's a large backlog of writes to a slow device is not the lemming-syncer problem. It's also not a lack of TCQ/NCQ slots, given that no such thing exists with SD card IO. When this is going on, the process driving the massive output spends almost all its time in a wdrain wait, and if you try to launch an app that isn't already in cache, a siginfo generally shows it to be in a getblk wait. -- IanReceived on Mon Mar 04 2013 - 14:16:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC