[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110330074123.GA17523@htj.dyndns.org>
Date: Wed, 30 Mar 2011 09:41:23 +0200
From: Tejun Heo <tj@...nel.org>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: Jeff Moyer <jmoyer@...hat.com>, Mike Snitzer <snitzer@...hat.com>,
Jens Axboe <axboe@...nel.dk>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
linux-kernel@...r.kernel.org, Chris Mason <chris.mason@...cle.com>
Subject: Re: [PATCH] block: eliminate ELEVATOR_INSERT_REQUEUE (was: Re:
elevator private data for REQ_FLUSH)
On Tue, Mar 29, 2011 at 01:54:58PM -0400, Vivek Goyal wrote:
> What is the significance of REQ_SOFTBARRIER? Why it should be set for all
> INSERT_FRONT and requeue requests.
>
> With flush logic we got rid of all hardbarriers and hence there is no
> notion of ordering as such. One has to wait for request to finish to
> enforce ordering.
>
> Should we get rid of softbarriers too?
REQ_SOFTBARRIER makes sure that other requests don't pass the barrier
ones when dispatched from the elevator to the dispatch queue. When
the request is being inserted explicitly at front, dispatching other
requests in front of it is a bit, umm, weird.
IIRC, at least in the requeue path, some drivers depend on front
queueing for forward progress guarantee. Forward progress for
prepping is guaranteed by mempool (or something like that) and when
the request is retried, it should stay at the front of the queue;
otherwise, prepping can stall with prepped requests stuck behind
unprepped ones.
Although flush requests don't need REQ_SOFTBARRIER anymore, I don't
think removing it would bring much benefit either, so no reason to
change it just for that reason.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists