On Wed, Oct 03, 2007 at 07:47:45AM +1000, David Chinner wrote:You mean slow writers and fast RAID? That would be exactly the case these patches try to improve. The old writeback behaviors are sluggish when there is - single big dirty file; - single congested device the queues may well build up slowly, hit background_limit, and continue to build up, until hit dirty_limit. That means: - kupdate writeback could leave behind many expired dirty data - background writeback used to return prematurely - eventually it relies on balance_dirty_pages() to do the job, which means - writers get throttled unnecessarily - dirty_limit pages are pinned unnecessarily This patchset makes kupdate/background writeback more responsible, so that if (avg-write-speed < device-capabilities), the dirty data are synced timely, and we don't have to go for balance_dirty_pages(). So for your question of queue depth, the answer is: the queue length will not build up in the first place. Also the name of congestion_wait() could be misleading: - when not congested, congestion_wait() will wakeup on write completions; - when congested, congestion_wait() could also wakeup on write completions on other non-congested devices. So congestion_wait(100ms) normally only takes 0.1-10ms. For the more_io case, congestion_wait() serves more like 'to take a breath'. Tests show that the system could go mad without it. Regards, Fengguang -
| Jeremy Fitzhardinge | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Mike Galbraith | Re: regression: CD burning (k3b) went broke |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Linus Torvalds | Re: [GIT]: Networking |
| Michael Grollman | Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945... |
