[lkml]   [2005]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][5/?] count writeback pages in nr_scanned
    Marcelo Tosatti wrote:
    >>The caller would need to wait on all the zones which can satisfy the
    >>caller's allocation request. A bit messy, although not rocket science.
    >>One would have to be careful to avoid additional CPU consumption due to
    >>delivery of multiple wakeups at each I/O completion.
    >>We should be able to demonstrate that such a change really fixes some
    >>problem though. Otherwise, why bother?
    > Agreed. The current scheme works well enough, we dont have spurious OOM kills
    > anymore, which is the only "problem" such change ought to fix.
    > You might have performance increase in some situations I believe (because you
    > have perzone waitqueues), but I agree its does not seem to be worth the
    > trouble.

    I think what Andrea is worried about is that blk_congestion_wait is
    fairly vague, and can be a source of instability in the scanning

    For example, if you have a heavy IO workload that is saturating your
    disks, blk_congestion_wait may do the right thing and sleep until
    they become uncongested and writeout can continue.

    But at 2:00 am, when your backup job is trickling writes into another
    block device, blk_congestion_wait returns much earlier, and before
    many pages have been cleaned.

    Bad example? Yeah maybe, but I think this is what Andrea is getting
    at. Would it be a problem to replace those blk_congestion_waits with
    unconditional io_schedule_timeout()s? That would be the dumb-but-more
    -deterministic solution.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean