[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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 <>
> >
> >
> >Looks good, thanks.
> >
> >Signed-off-by: Jens Axboe <>
> >
> 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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.110 / U:1.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site