lkml.org 
[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: ll_rw_blk.c fails to merge requests. Help!
    On  August 23, torvalds@transmeta.com wrote:
    > In article <14756.25889.655254.332719@notabene.cse.unsw.edu.au>,
    > Neil Brown <neilb@cse.unsw.edu.au> wrote:
    > >
    > >Not necessarily. When a request is freed, the oldest waiting thread
    > >is woken, but it might not actually get to run before some other
    > >thread steals the request. You could force a strict ordering if you
    > >really wanted to, but I don't know how much it would help. See
    > >STRICT_REQUEST_ORDERING in the patch below.
    >
    > Neil, I suspect the request ordering is secondary, and the real problem
    > is that at some point we get into this awful steady state where we
    > create new requests at the same pace as we get rid of old ones, and we
    > always end up waiting for the next request to be free'd.

    I agree. I only commented becuase the orginal question asked about
    this and I thought "couldn't hurt to try and see if it makes a
    difference.

    What I think the "real issue" is (and was addressed by the rest of the
    patch but possibly wasn't presented very clearly) is the following:

    1/ request for block A arrives. We have no spare requests so we
    sleep.
    2/ request for block B arrives (B continguous with A). We have no
    spare requests so we sleep.
    3/ something completes, first thread is woken up and it uses the
    request.
    4/ something else completes, second thread is woken up. Now it's
    request for block B could be merged with the request for block A,
    but it doesn't bother, it just adds a new request.

    This seemed to be what was happening the the trace given.
    If two threads, say kupdate and kflushd are both running
    flush_dirty_buffers, and the buffers are in device-sequential order,
    then we would have them alternately writing sequential blocks.
    One the request queue was full, each would block waiting for a
    request, and then fail to merge with the request that was just
    scheduled by the other.
    Net result - lots of small write requests on the queue that could be
    merged but aren't.

    Hence the code in my patch that went back and tried again to merge
    requests after waiting for a request structure.

    >
    > The normal elevator thing obviously tries to merge first, so truly
    > contiguous entries should get merged regardless of whether there are any
    > free requests or not. However, we should try to get the "not quite
    > contiguous" case right too. And I'm not convinced my theory above is
    > valid, but I can see that there could indeed be some bad behaviour
    > patterns if we only have one request free at any particular time..

    I think that providing every opportunity to merge requests is taken
    (see above), there shouldn't be any problems with "only one free
    request" situations. The queue is (should be) sufficiently long to
    decouple handling of requests off the front from adding new requests to
    the end. A bunch of read requests should all have a chance of getting
    onto the queue and being merged where appropriate before any of them
    get processed. If not, then MAX_READAHEAD is too large, or
    QUEUE_NR_REQUESTS is too small (or we need to get the READA command
    down to ll_rw_block from generic_file_readahead).

    NeilBrown
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:3.595 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site