lkml.org 
[lkml]   [2005]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][5/?] count writeback pages in nr_scanned
    Andrea Arcangeli wrote:
    > On Wed, Jan 05, 2005 at 09:05:39PM -0800, Andrew Morton wrote:
    >
    >>Andrea Arcangeli <andrea@suse.de> wrote:
    >>
    >>>The fix is very simple and it is to call wait_on_page_writeback on one
    >>> of the pages under writeback.
    >>
    >>eek, no. That was causing waits of five seconds or more. Fixing this
    >>caused the single greatest improvement in page allocator latency in early
    >>2.5. We're totally at the mercy of the elevator algorithm this way.
    >>
    >>If we're to improve things in there we want to wait on _any_ eligible page
    >>becoming reclaimable, not on a particular page.
    >
    >
    > I told you one way to fix it. I didn't guarantee it was the most
    > efficient one.
    >
    > I sure agree waiting on any page to complete writeback is going to fix
    > it too. Exactly because this page was a "random" page anyway.
    >
    > Still my point is that this is a bug, and I prefer to be slow and safe
    > like 2.4, than fast and unreliable like 2.6.
    >
    > The slight improvement you suggested of waiting on _any_ random
    > PG_writeback to go away (instead of one particular one as I did in 2.4)
    > is going to fix the write throttling equally too as well as the 2.4
    > logic, but without introducing slowdown that 2.4 had.
    >
    > It's easy to demonstrate: exactly because the page we pick is random
    > anyway, we can pick the first random one that has seen PG_writeback
    > transitioning from 1 to 0. The guarantee we get is the same in terms of
    > safety of the write throttling, but we also guarantee the best possible
    > latency this way. And the HZ/x hacks to avoid deadlocks will magically
    > go away too.
    >

    This is practically what blk_congestion_wait does when the queue
    isn't congested though, isn't it?
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.022 / U:154.024 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site