lkml.org 
[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] use cheaper elv_queue_empty when unplug a device
    On Tue, Mar 29 2005, Nick Piggin wrote:
    > Jens Axboe wrote:
    > >On Mon, Mar 28 2005, Chen, Kenneth W wrote:
    > >
    > >>This patch was posted last year and if I remember correctly, Jens said
    > >>he is OK with the patch. In function __generic_unplug_deivce(), kernel
    > >>can use a cheaper function elv_queue_empty() instead of more expensive
    > >>elv_next_request to find whether the queue is empty or not. blk_run_queue
    > >>can also made conditional on whether queue's emptiness before calling
    > >>request_fn().
    > >>
    > >>
    > >>Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
    > >
    > >
    > >Looks good, thanks.
    > >
    > >Signed-off-by: Jens Axboe <axboe@suse.de>
    > >
    >
    > Speaking of which, I've had a few ideas lying around for possible
    > performance improvement in the block code.
    >
    > I haven't used a big disk array (or tried any simulation), but I'll
    > attach the patch if you're looking into that area.
    >
    > It puts in a few unlikely()s, but the main changes are:
    > - don't generic_unplug_device unconditionally in get_request_wait,
    > - removes the relock/retry merge mechanism in __make_request if we
    > aren't able to get the GFP_ATOMIC allocation. Just fall through
    > and assume the chances of getting a merge will be small (is this
    > a valid assumption? Should measure it I guess).
    > - removes the GFP_ATOMIC allocation. That's always a good thing.

    Looks good, I've been toying with something very similar for a long time
    myself.

    The unplug change is a no-brainer. The retry stuff i __make_request()
    will make no real difference on 'typical' hardware, when it was
    introduced in 2.4.x it was very useful on slower devices like dvd-rams.
    The batch wakeups should take care of this.

    The atomic-vs-blocking allocation should be tested. I'd really like it
    to be a "don't dive into the vm very much, just wait on the mempool"
    type allocation, so we are not at the mercy of long vm reclaim times
    hurting the latencies here.

    --
    Jens Axboe

    -
    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-04-06 13:31    [W:0.034 / U:0.080 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site