All of lore.kernel.org
 help / color / mirror / Atom feed
From: axboe@fb.com (Jens Axboe)
Subject: [PATCH v10] NVMe: Convert to blk-mq
Date: Wed, 23 Jul 2014 21:07:31 +0200	[thread overview]
Message-ID: <53D007F3.4040006@fb.com> (raw)
In-Reply-To: <53D005D6.8050302@bjorling.me>

On 2014-07-23 20:58, Matias Bjorling wrote:
>>> +    iod = nvme_alloc_iod(psegs, blk_rq_bytes(req), GFP_ATOMIC);
>>>       if (!iod)
>>> +        return result;
>>
>> So there's still a memory allocation for each request here.  Any reason
>> this can't be preallocated at least for reasonable sized I/O?
>
> Not at all. I've kept from adding optimizations in the first pass. The
> patches following can implement the optimizations. Jens already has a
> patch for this in his tree. It also removes GFP_ATOMIC.

That is correct, and that is the way the series should be done. I've got 
patches getting rid of this allocation for smaller IO:

http://git.kernel.dk/?p=linux-block.git;a=commit;h=04497c3394f3220111d4274704a1ff6bdd3ceae3

which is a noticable win for high IOPS smaller IO.

>> Seems like blk-mq would make your life easier by exporting an iterator
>> that goes over each in-use request instead of the current
>> blk_mq_tag_busy_iter prototype.  blk_mq_timeout_check would also be able
>> to make use of that, so maybe that would be a good preparatory patch?
>
> Yes. I'll prepare a patch and send it off to Jens.

Thanks, that will clean it up nicely. It's a bit backwards these days, 
since the mechanism got changed.


-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@fb.com>
To: Matias Bjorling <m@bjorling.me>, Christoph Hellwig <hch@infradead.org>
Cc: <willy@linux.intel.com>, <keith.busch@intel.com>,
	<sbradshaw@micron.com>, <tom.leiming@gmail.com>,
	<rlnelson@google.com>, <linux-kernel@vger.kernel.org>,
	<linux-nvme@lists.infradead.org>
Subject: Re: [PATCH v10] NVMe: Convert to blk-mq
Date: Wed, 23 Jul 2014 21:07:31 +0200	[thread overview]
Message-ID: <53D007F3.4040006@fb.com> (raw)
In-Reply-To: <53D005D6.8050302@bjorling.me>

On 2014-07-23 20:58, Matias Bjorling wrote:
>>> +    iod = nvme_alloc_iod(psegs, blk_rq_bytes(req), GFP_ATOMIC);
>>>       if (!iod)
>>> +        return result;
>>
>> So there's still a memory allocation for each request here.  Any reason
>> this can't be preallocated at least for reasonable sized I/O?
>
> Not at all. I've kept from adding optimizations in the first pass. The
> patches following can implement the optimizations. Jens already has a
> patch for this in his tree. It also removes GFP_ATOMIC.

That is correct, and that is the way the series should be done. I've got 
patches getting rid of this allocation for smaller IO:

http://git.kernel.dk/?p=linux-block.git;a=commit;h=04497c3394f3220111d4274704a1ff6bdd3ceae3

which is a noticable win for high IOPS smaller IO.

>> Seems like blk-mq would make your life easier by exporting an iterator
>> that goes over each in-use request instead of the current
>> blk_mq_tag_busy_iter prototype.  blk_mq_timeout_check would also be able
>> to make use of that, so maybe that would be a good preparatory patch?
>
> Yes. I'll prepare a patch and send it off to Jens.

Thanks, that will clean it up nicely. It's a bit backwards these days, 
since the mechanism got changed.


-- 
Jens Axboe


  reply	other threads:[~2014-07-23 19:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 14:53 [PATCH v10] Convert NVMe driver to blk-mq Matias Bjørling
2014-07-01 14:53 ` Matias Bjørling
2014-07-01 14:53 ` [PATCH v10] NVMe: Convert " Matias Bjørling
2014-07-01 14:53   ` Matias Bjørling
2014-07-14 12:41   ` Christoph Hellwig
2014-07-14 12:41     ` Christoph Hellwig
2014-07-23 18:58     ` Matias Bjorling
2014-07-23 18:58       ` Matias Bjorling
2014-07-23 19:07       ` Jens Axboe [this message]
2014-07-23 19:07         ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D007F3.4040006@fb.com \
    --to=axboe@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.