Messages in this thread | | | Date | Sat, 3 Oct 2009 14:10:44 +0800 | From | Wu Fengguang <> | Subject | Re: regression in page writeback |
| |
On Sat, Oct 03, 2009 at 01:26:20AM +0800, Theodore Ts'o wrote: > On Fri, Oct 02, 2009 at 04:19:53PM +0800, Wu Fengguang wrote: > > > > The big writes, if they are contiguous, could take 1-2 seconds > > > > on a very slow, ancient laptop disk, and that will hold up any kind of > > > > small synchornous activities --- such as either a disk read or a firefox- > > > > triggered fsync(). > > > > > > Yes, that's a problem. The SYNC/ASYNC elevator queues can help here. > > The SYNC/ASYNC queues will partially help, up to the whatever the > largest I/O that can issued as a single chunk times the queue depth > for those disks that support NCQ. > > > > There's still the problem of IO submission time != IO completion time, > > > due to fluctuations of randomness and more. However that's a general > > > and unavoidable problem. Both the wbc.timeout scheme and the > > > "wbc.nr_to_write based on estimated throughput" scheme are based on > > > _past_ requests and it's simply impossible to have a 100% accurate > > > scheme. In principle, wbc.timeout will only be inferior at IO startup > > > time. In the steady state of 100% full queue, it is actually estimating > > > the IO throughput implicitly :) > > > > Another difference between wbc.timeout and adaptive wbc.nr_to_write > > is, when there comes many _read_ requests or fsync, these SYNC rw > > requests will significant lower the ASYNC writeback throughput, if > > it's not completely stalled. So with timeout, the inode will be > > aborted with few pages written; with nr_to_write, the inode will be > > written a good number of pages, at the cost of taking up long time. > > > > IMHO the nr_to_write behavior seems more efficient. What do you think? > > I agree, adaptively changing nr_to_write seems like the right thing to
I'd like to estimate the writeback throughput in bdi_writeback_wakeup(), where the queue is not starved and the estimation would reflect the max device capability (unless there are busy reads, in which case we need lower nr_to_write anyway).
> do. For bonus points, we could also monitor how often synchronous I/O > operations are happening, allow nr_to_write to go up by some amount if > there aren't many synchronous operations happening at the moment. So > that might be another opportunity to do auto-tuning, although this > might be a hueristic that might need to be configurable for certain > specialized workloads. For many other workloads, the it should be > possible to detect regular pattern of reads and/or synchronous writes, > and if so, use a lower nr_to_write versus if there isn't many > synchronous I/O operations happening on that particular block device.
It's not easy to get state of the art SYNC read/write busyness. However it is possible to "feel" them through the progress of ASYNC writes.
- setup a per-file timeout=3*HZ - check this in write_cache_pages:
if (half nr_to_write pages written && timeout) break;
In this way we back off to nr_to_write/2 if the writeback is blocked by some busy READs.
I'd choose to implement this advanced feature some time later :)
Thanks, Fengguang
| |