Re: block: eliminate ELEVATOR_INSERT_REQUEUE
From: Mike Snitzer
Date: Wed Mar 30 2011 - 10:01:47 EST
On Wed, Mar 30 2011 at 4:02am -0400,
Tejun Heo <tj@xxxxxxxxxx> wrote:
> Hello, Jens.
>
> On Wed, Mar 30, 2011 at 09:59:09AM +0200, Jens Axboe wrote:
> > Pure front insert should be used for requeue and internal commands (like
> > spin up this drive, or get error information). Flush should append to
> > the dispatch list.
>
> Yeah, right. The reason I used REQUEUE/FRONT was because BACK
> insertion involves draining the elevator and then appending the
> request at the end of the dispatch queue, which is unnecessary and
> inefficient. So, front insertion was a quick work around that. If
> we're removing elv_insert(), we can just append directly to the
> dispatch queue from flush code.
I'm trying to follow along but unrolling what was said above is
challenging considering we're not getting rid of elv_insert()'s
functionality; it was just folded into __elv_add_request() -- offering
no functional change AFAIK. So placing special meaning on getting rid
of elv_insert() is confusing me.
Why can we all of a sudden append the flush to the dispatch queue _but_
not have any concern about queue draining? Seems that avoiding use of
BACK, by using list_add_tail, is enabling that. Couldn't we have always
done that? The folding of elv_insert() into __elv_add_request() seems
irrelevant.
Can we take a step back and be more explicit about the implications of
having inserted the flush with REQUEUE/FRONT? Seems to me that having
_not_ inserted the flush at the end of the dispatch queue is cause for
potential corruption (preceding data hasn't been issued to the device
yet).
And just to be clear: none of this is a concern for stable right? It is
just the flush-merge code introduced for 2.6.39 that needs fixing?
Please advise, thanks!
Mike
--
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/