On 11/29/18 6:20 PM, Keith Busch wrote:
On Thu, Nov 29, 2018 at 06:11:59PM +0100, Christoph Hellwig wrote:
diff --git a/block/blk-mq.c b/block/blk-mq.c
index a82830f39933..d0ef540711c7 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -647,7 +647,7 @@ EXPORT_SYMBOL(blk_mq_complete_request);
On Thu, Nov 29, 2018 at 06:11:59PM +0100, Christoph Hellwig wrote:
> > diff --git a/block/blk-mq.c b/block/blk-mq.c
> > index a82830f39933..d0ef540711c7 100644
> > --- a/block/blk-mq.c
> > +++ b/block/blk-mq.c
> > @@ -647,7 +647,7 @@ EXPORT_SYMBOL(blk_mq_complete_request);
> >
> > int blk_mq_req
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index a82830f39933..d0ef540711c7 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -647,7 +647,7 @@ EXPORT_SYMBOL(blk_mq_complete_request);
>
> int blk_mq_request_started(struct request *rq)
> {
> - return blk_mq_rq_state(rq) != MQ_RQ
On Wed, Nov 28, 2018 at 09:39:44PM -0500, Martin K. Petersen wrote:
>
> Ming,
>
> > On Wed, Nov 28, 2018 at 11:08:48AM +0100, Christoph Hellwig wrote:
> >> On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:
> >> > > Is this the nvme target on top of null_blk?
> >> >
> >> > Yes.
> >>
> >>
Ming,
> On Wed, Nov 28, 2018 at 11:08:48AM +0100, Christoph Hellwig wrote:
>> On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:
>> > > Is this the nvme target on top of null_blk?
>> >
>> > Yes.
>>
>> And it goes away if you revert just the last patch?
>
> Today I run this test again an
On Wed, Nov 28, 2018 at 11:08:48AM +0100, Christoph Hellwig wrote:
> On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:
> > > Is this the nvme target on top of null_blk?
> >
> > Yes.
>
> And it goes away if you revert just the last patch?
Today I run this test again and can't reproduce it
On Wed, Nov 28, 2018 at 10:56:25AM -0700, Keith Busch wrote:
> On Wed, Nov 28, 2018 at 09:26:55AM -0700, Keith Busch wrote:
> > ---
> > diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
> > index 9908082b32c4..116398b240e5 100644
> > --- a/drivers/nvme/target/loop.c
> > +++ b/dri
On Wed, Nov 28, 2018 at 03:31:46PM -0700, Keith Busch wrote:
> Waiting for a freeze isn't really the criteria we need anyway: we don't
> care if there are entered requests in REQ_MQ_IDLE. We just want to wait
> for dispatched ones to return, and we currently don't have a good way
> to sync with tha
On Wed, Nov 28, 2018 at 09:26:55AM -0700, Keith Busch wrote:
> ---
> diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
> index 9908082b32c4..116398b240e5 100644
> --- a/drivers/nvme/target/loop.c
> +++ b/drivers/nvme/target/loop.c
> @@ -428,10 +428,14 @@ static int nvme_loop_conf
On Wed, Nov 28, 2018 at 09:26:55AM -0700, Keith Busch wrote:
> ---
> diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
> index 9908082b32c4..116398b240e5 100644
> --- a/drivers/nvme/target/loop.c
> +++ b/drivers/nvme/target/loop.c
> @@ -428,10 +428,14 @@ static int nvme_loop_conf
On 11/28/18 9:26 AM, Keith Busch wrote:
> On Wed, Nov 28, 2018 at 08:58:00AM -0700, Jens Axboe wrote:
>> On 11/28/18 8:49 AM, Keith Busch wrote:
>>> On Wed, Nov 28, 2018 at 11:08:48AM +0100, Christoph Hellwig wrote:
On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:
>> Is this the n
On Wed, Nov 28, 2018 at 08:58:00AM -0700, Jens Axboe wrote:
> On 11/28/18 8:49 AM, Keith Busch wrote:
> > On Wed, Nov 28, 2018 at 11:08:48AM +0100, Christoph Hellwig wrote:
> >> On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:
> Is this the nvme target on top of null_blk?
> >>>
> >>>
On 11/28/18 8:49 AM, Keith Busch wrote:
> On Wed, Nov 28, 2018 at 11:08:48AM +0100, Christoph Hellwig wrote:
>> On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:
Is this the nvme target on top of null_blk?
>>>
>>> Yes.
>>
>> And it goes away if you revert just the last patch?
>
> It l
On Wed, Nov 28, 2018 at 11:08:48AM +0100, Christoph Hellwig wrote:
> On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:
> > > Is this the nvme target on top of null_blk?
> >
> > Yes.
>
> And it goes away if you revert just the last patch?
It looks like a problem existed before that last p
On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:
> > Is this the nvme target on top of null_blk?
>
> Yes.
And it goes away if you revert just the last patch?
On Wed, Nov 28, 2018 at 08:00:10AM +0100, Christoph Hellwig wrote:
> On Wed, Nov 28, 2018 at 10:20:01AM +0800, Ming Lei wrote:
> > On Mon, Nov 26, 2018 at 10:33:32AM -0700, Jens Axboe wrote:
> > > On 11/26/18 9:54 AM, Keith Busch wrote:
> > > > The iterative update to the previous version taking in
On Wed, Nov 28, 2018 at 10:20:01AM +0800, Ming Lei wrote:
> On Mon, Nov 26, 2018 at 10:33:32AM -0700, Jens Axboe wrote:
> > On 11/26/18 9:54 AM, Keith Busch wrote:
> > > The iterative update to the previous version taking into account review
> > > comments.
> > >
> > > Background:
> > >
> > > The
On Mon, Nov 26, 2018 at 10:33:32AM -0700, Jens Axboe wrote:
> On 11/26/18 9:54 AM, Keith Busch wrote:
> > The iterative update to the previous version taking into account review
> > comments.
> >
> > Background:
> >
> > The main objective is to remove the generic block layer's lock prefix
> > cur
On 11/26/18 9:54 AM, Keith Busch wrote:
> The iterative update to the previous version taking into account review
> comments.
>
> Background:
>
> The main objective is to remove the generic block layer's lock prefix
> currently required to transition a request to its completed state by
> shifting
The iterative update to the previous version taking into account review
comments.
Background:
The main objective is to remove the generic block layer's lock prefix
currently required to transition a request to its completed state by
shifting that expense to lower level drivers that actually need
20 matches
Mail list logo
