Re: block: eliminate ELEVATOR_INSERT_REQUEUE

[Mike Snitzer <snitzer@redhat.com>]

On Wed, Mar 30 2011 at  4:02am -0400,
Tejun Heo <tj@kernel.org> 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