[lkml]   [2002]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: queue_nr_requests needs to be selective
    "Jeff V. Merkey" wrote:
    > Linus/Alan/Linux,
    > Performance numbers can be increased dramatically (> 300 MB/S)
    > by increasing queue_nr_requests in ll_rw_blk.c on large RAID
    > controllers that are hosting a lot of drives.

    I don't immediately see why increasing the queue length should
    increase bandwidth in this manner. One possibility is that
    the shorter queue results in tasks sleeping in __get_request_wait
    more often, and the real problem is the "request starvation" thing.

    The "request starvation" thing could conceivably result in more
    seeky behaviour. In your kernel, disk writeouts come from
    two places:

    - Off the tail of the dirty buffer LRU

    - Basically random guess, from the page LRU.

    It's competition between these two writeout sources which causes
    decreased bandwidth - I've seen kernels in which ext2 writeback
    performance was down 40% due to this.

    Anyway. You definitely need to try 2.4.19-pre1. Max sleep times
    in __get_request_wait will be improved, and it's possible that the
    bandwidth will improve. Or not. My gut feel is that it won't

    And yes, 128 requests is too few. It used to be ~1000. I think
    this change was made in a (misguided, unsuccessful) attempt to
    manage latency for readers. The request queue is the only mechanism
    we have for realigning out-of-order requests and it needs to be
    larger so it can do this better. I've seen 15-25% throughput
    improvements from a 1024-slot request queue.

    And if a return to a large request queue damages latency (it doesn't)
    then we need to fix that latency *without* damaging request merging.

    First step: please test 2.4.19-pre1 or -pre2. Also 2.4.19-pre1-ac2
    may provide some surprises..

    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 13:24    [W:0.026 / U:0.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site