On 12/4/2018 1:21 PM, Keith Busch wrote:
On Tue, Dec 04, 2018 at 11:33:33AM -0800, James Smart wrote:
I disagree. The cases I've run into are on the admin queue - where we are
sending io to initialize the controller when another error/reset occurs, and
the checks are required to identify/rej
On Tue, Dec 04, 2018 at 02:21:17PM -0700, Keith Busch wrote:
> On Tue, Dec 04, 2018 at 11:33:33AM -0800, James Smart wrote:
> > On 12/4/2018 9:48 AM, Keith Busch wrote:
> > > Once quiesced, the proposed iterator can handle the final termination
> > > of the request, perform failover, or some other
On Tue, Dec 04, 2018 at 11:33:33AM -0800, James Smart wrote:
>
>
> On 12/4/2018 9:48 AM, Keith Busch wrote:
> > On Tue, Dec 04, 2018 at 09:38:29AM -0800, Sagi Grimberg wrote:
> > > > > > Yes, I'm very much in favour of this, too.
> > > > > > We always have this IMO slightly weird notion of stoppi
On 12/4/2018 9:48 AM, Keith Busch wrote:
On Tue, Dec 04, 2018 at 09:38:29AM -0800, Sagi Grimberg wrote:
Yes, I'm very much in favour of this, too.
We always have this IMO slightly weird notion of stopping the queue, set
some error flags in the driver, then _restarting_ the queue, just so
that
On 12/4/2018 9:23 AM, Sagi Grimberg wrote:
Yes, I'm very much in favour of this, too.
We always have this IMO slightly weird notion of stopping the
queue, set
some error flags in the driver, then _restarting_ the queue, just so
that the driver then sees the error flag and terminates the re
On Tue, Dec 04, 2018 at 09:38:29AM -0800, Sagi Grimberg wrote:
>
> > > > Yes, I'm very much in favour of this, too.
> > > > We always have this IMO slightly weird notion of stopping the queue, set
> > > > some error flags in the driver, then _restarting_ the queue, just so
> > > > that the driver
Yes, I'm very much in favour of this, too.
We always have this IMO slightly weird notion of stopping the queue, set
some error flags in the driver, then _restarting_ the queue, just so
that the driver then sees the error flag and terminates the requests.
Which I always found quite counter-intui
Yes, I'm very much in favour of this, too.
We always have this IMO slightly weird notion of stopping the queue,
set
some error flags in the driver, then _restarting_ the queue, just so
that the driver then sees the error flag and terminates the requests.
Which I always found quite counter-int
On 12/4/2018 7:46 AM, Keith Busch wrote:
On Mon, Dec 03, 2018 at 05:33:06PM -0800, Sagi Grimberg wrote:
Yes, I'm very much in favour of this, too.
We always have this IMO slightly weird notion of stopping the queue, set
some error flags in the driver, then _restarting_ the queue, just so
that th
On Mon, Dec 03, 2018 at 05:33:06PM -0800, Sagi Grimberg wrote:
> >>
> > Yes, I'm very much in favour of this, too.
> > We always have this IMO slightly weird notion of stopping the queue, set
> > some error flags in the driver, then _restarting_ the queue, just so
> > that the driver then sees th
A driver may wish to iterate every tagged request, not just ones that
satisfy blk_mq_request_started(). The intended use is so a driver may
terminate entered requests on quiesced queues.
How about we just move the started check into the handler passed in for
those that care about it? Much san
On 12/1/2018 10:32 AM, Bart Van Assche wrote:
On 12/1/18 9:11 AM, Hannes Reinecke wrote:
Yes, I'm very much in favour of this, too.
We always have this IMO slightly weird notion of stopping the queue,
set some error flags in the driver, then _restarting_ the queue, just
so that the driver
On Sun, Dec 2, 2018 at 12:48 AM Christoph Hellwig wrote:
>
> On Fri, Nov 30, 2018 at 01:36:09PM -0700, Jens Axboe wrote:
> > On 11/30/18 1:26 PM, Keith Busch wrote:
> > > A driver may wish to iterate every tagged request, not just ones that
> > > satisfy blk_mq_request_started(). The intended use
On 12/1/18 9:11 AM, Hannes Reinecke wrote:
On 12/1/18 5:48 PM, Christoph Hellwig wrote:
On Fri, Nov 30, 2018 at 01:36:09PM -0700, Jens Axboe wrote:
On 11/30/18 1:26 PM, Keith Busch wrote:
A driver may wish to iterate every tagged request, not just ones that
satisfy blk_mq_request_started(). Th
On 12/1/18 5:48 PM, Christoph Hellwig wrote:
On Fri, Nov 30, 2018 at 01:36:09PM -0700, Jens Axboe wrote:
On 11/30/18 1:26 PM, Keith Busch wrote:
A driver may wish to iterate every tagged request, not just ones that
satisfy blk_mq_request_started(). The intended use is so a driver may
terminate
On Fri, Nov 30, 2018 at 01:36:09PM -0700, Jens Axboe wrote:
> On 11/30/18 1:26 PM, Keith Busch wrote:
> > A driver may wish to iterate every tagged request, not just ones that
> > satisfy blk_mq_request_started(). The intended use is so a driver may
> > terminate entered requests on quiesced queues
On Fri, Nov 30, 2018 at 01:36:09PM -0700, Jens Axboe wrote:
> On 11/30/18 1:26 PM, Keith Busch wrote:
> > A driver may wish to iterate every tagged request, not just ones that
> > satisfy blk_mq_request_started(). The intended use is so a driver may
> > terminate entered requests on quiesced queues
On 11/30/18 1:26 PM, Keith Busch wrote:
> A driver may wish to iterate every tagged request, not just ones that
> satisfy blk_mq_request_started(). The intended use is so a driver may
> terminate entered requests on quiesced queues.
How about we just move the started check into the handler passed
A driver may wish to iterate every tagged request, not just ones that
satisfy blk_mq_request_started(). The intended use is so a driver may
terminate entered requests on quiesced queues.
Signed-off-by: Keith Busch
---
block/blk-mq-tag.c | 41 +++--
block/b
19 matches
Mail list logo