Re: [patch] use cheaper elv_queue_empty when unplug a device

[Jens Axboe]

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@xxxxxxxxx>
> >
> >
> >Looks good, thanks.
> >
> >Signed-off-by: Jens Axboe <axboe@xxxxxxx>
> >
> 
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/