* BLK_MQ_F_DEFER_ISSUE
@ 2015-04-20 15:09 Jeff Moyer
2015-04-20 15:58 ` BLK_MQ_F_DEFER_ISSUE Jens Axboe
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Moyer @ 2015-04-20 15:09 UTC (permalink / raw)
To: Jens Axboe, lkml
Hi, Jens,
This flag was introduced under the auspices that the nvme blk-mq
conversion would make use of it. That never materialized. Are there
still plans to make use of it? If not, I'd like to get rid of it. If
so, then let's document it better.
Cheers,
Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BLK_MQ_F_DEFER_ISSUE
2015-04-20 15:09 BLK_MQ_F_DEFER_ISSUE Jeff Moyer
@ 2015-04-20 15:58 ` Jens Axboe
2015-04-20 16:04 ` BLK_MQ_F_DEFER_ISSUE Jeff Moyer
0 siblings, 1 reply; 3+ messages in thread
From: Jens Axboe @ 2015-04-20 15:58 UTC (permalink / raw)
To: Jeff Moyer, lkml
On 04/20/2015 09:09 AM, Jeff Moyer wrote:
> Hi, Jens,
>
> This flag was introduced under the auspices that the nvme blk-mq
> conversion would make use of it. That never materialized. Are there
> still plans to make use of it? If not, I'd like to get rid of it. If
> so, then let's document it better.
Yep I still want to use it, and I do have a patch that uses it as well
that I've run through testing. I thought I had pushed it somewhere, but
it doesn't seem like I have. I just wanted to get the lower hanging
optimizations out there first, like the kmalloc/kfree and
queue-lock-for-completions removal. Former is in, latter is not yet.
It's a useful optimization for lots of cases and I'm sure it'll see
other uses, once the nvme patch is in. That will give people a reference
point.
--
Jens Axboe
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BLK_MQ_F_DEFER_ISSUE
2015-04-20 15:58 ` BLK_MQ_F_DEFER_ISSUE Jens Axboe
@ 2015-04-20 16:04 ` Jeff Moyer
0 siblings, 0 replies; 3+ messages in thread
From: Jeff Moyer @ 2015-04-20 16:04 UTC (permalink / raw)
To: Jens Axboe; +Cc: lkml
Jens Axboe <axboe@kernel.dk> writes:
> On 04/20/2015 09:09 AM, Jeff Moyer wrote:
>> Hi, Jens,
>>
>> This flag was introduced under the auspices that the nvme blk-mq
>> conversion would make use of it. That never materialized. Are there
>> still plans to make use of it? If not, I'd like to get rid of it. If
>> so, then let's document it better.
>
> Yep I still want to use it, and I do have a patch that uses it as well
> that I've run through testing. I thought I had pushed it somewhere,
> but it doesn't seem like I have. I just wanted to get the lower
> hanging optimizations out there first, like the kmalloc/kfree and
> queue-lock-for-completions removal. Former is in, latter is not yet.
>
> It's a useful optimization for lots of cases and I'm sure it'll see
> other uses, once the nvme patch is in. That will give people a
> reference point.
OK, thanks for the quick reply.
-Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-04-20 16:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-20 15:09 BLK_MQ_F_DEFER_ISSUE Jeff Moyer
2015-04-20 15:58 ` BLK_MQ_F_DEFER_ISSUE Jens Axboe
2015-04-20 16:04 ` BLK_MQ_F_DEFER_ISSUE Jeff Moyer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.