[lkml]   [2009]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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?


     \ /
      Last update: 2009-09-25 05:23    [W:0.022 / U:12.592 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site