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


    Dave Chinner

     \ /
      Last update: 2009-09-25 02:15    [W:0.021 / U:6.484 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site