Messages in this thread | | | Date | Wed, 16 Aug 2006 09:00:50 +1000 | From | David Chinner <> | Subject | Re: RFC - how to balance Dirty+Writeback in the face of slow writeback. |
| |
On Tue, Aug 15, 2006 at 01:06:11AM -0700, Andrew Morton wrote: > On Tue, 15 Aug 2006 09:40:12 +1000 > Neil Brown <neilb@suse.de> wrote: > > When Dirty hits 0 (and Writeback is theoretically 80% of RAM) > > balance_dirty_pages will no longer be able to flush the full > > 'write_chunk' (1.5 times number of recent dirtied pages) and so will > > spin in a loop calling blk_congestion_wait(WRITE, HZ/10), so it isn't > > a busy loop, but it won't progress. > > This assumes that the queues are unbounded. They're not - they're limited > to 128 requests, which is 60MB or so. > > Per queue. The scenario you identify can happen if it's spread across > multiple disks simultaneously.
Though in this situation, you don't usually have slow writeback problems. I haven't seen any recent problems with insufficient throttling on this sort of configuration.
> CFQ used to have 1024 requests and we did have problems with excessive > numbers of writeback pages. I fixed that in 2.6.early, but that seems to > have got lost as well.
CFQ still has a queue depth of 128 requests....
> > bdflush should get some writeback underway before we hit the 40%, so > > balance_dirty_pages shouldn't find itself waiting for the pages it > > just flushed.
balance_dirty_pages() already kicks the background writeback done by pdflush when dirty > dirty_background_ratio (10%).
IMO, if you've got slow writeback, you should be reducing the amount of dirty memory you allow in the machine so that you don't tie up large amounts of memory that takes a long time to clean. Throttle earlier and you avoid this problem entirely.
Cheers,
Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |