Messages in this thread | | | Date | Fri, 25 Sep 2009 11:19:20 +0800 | From | Wu Fengguang <> | Subject | Re: regression in page writeback |
| |
On Fri, Sep 25, 2009 at 08:11:17AM +0800, Dave Chinner wrote: > On Thu, Sep 24, 2009 at 11:15:08AM +0800, Wu Fengguang wrote: > > On Wed, Sep 23, 2009 at 10:00:58PM +0800, Chris Mason wrote: > > > The only place that actually honors the congestion flag is pdflush. > > > It's trivial to get pdflush backed up and make it sit down without > > > making any progress because once the queue congests, pdflush goes away. > > > > Right. I guess that's more or less intentional - to give lowest priority > > to periodic/background writeback. > > IMO, this is the wrong design. Background writeback should > have higher CPU/scheduler priority than normal tasks. If there is > sufficient dirty pages in the system for background writeback to > be active, it should be running *now* to start as much IO as it can > without being held up by other, lower priority tasks. > > Cleaning pages is important to keeping the system running smoothly. > Given that IO takes time to clean pages, it is therefore important > to issue as much as possible as quickly as possible without delays > before going back to sleep. Delaying issue of the IO or doing > sub-optimal issue simply reduces performance of the system because > it takes longer to clean the same number of dirty pages. > > > > Nothing stops other procs from keeping the queue congested forever. > > > This can only be fixed by making everyone wait for congestion, at which > > > point we might as well wait for requests. > > > > Yes. That gives everyone somehow equal opportunity, this is a policy change > > that may lead to interesting effects, as well as present a challenge to > > get_request_wait(). That said, I'm not against the change to a wait queue > > in general. > > If you block all threads doing _writebehind caching_ (synchronous IO > is self-throttling) to the same BDI on the same queue as the bdi > flusher then when congestion clears the higher priority background > flusher thread should run first and issue more IO. This should > happen as a natural side-effect of our scheduling algorithms and it > gives preference to efficient background writeback over in-efficient > foreground writeback. Indeed, with this approach we can even avoid > foreground writeback altogether...
I don't see how balance_dirty_pages() writeout is less efficient than pdflush writeout.
They all called the same routines to do the job. balance_dirty_pages() sets nr_to_write=1536 at least for ext4 and xfs (unless memory is tight; btrfs is 1540), which is in fact 50% bigger than the 1024 pages used by pdflush. And it won't back off on congestion. The s_io/b_io queues are shared, so a balance_dirty_pages() will just continue from where the last sync thread exited. So it does not make much difference who initiates the IO. Did I missed something?
Thanks, Fengguang
| |