Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1486519

Re: [PATCH RFC 00/21] blk-mq: Introduce combined hardware queues

From Bart Van Assche <Bart.VanAssche@sandisk.com>
Newsgroups linux.kernel
Subject Re: [PATCH RFC 00/21] blk-mq: Introduce combined hardware queues
Date 2016-09-19 15:50 +0200
Message-ID <sj77j-65S-3@gated-at.bofh.it> (permalink)
References <shXa1-2mV-3@gated-at.bofh.it> <si8oN-1p6-3@gated-at.bofh.it> <sj49r-4fU-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 09/19/16 03:38, Alexander Gordeev wrote:
> On Fri, Sep 16, 2016 at 05:04:48PM -0400, Keith Busch wrote:
>
> CC-ing linux-block@vger.kernel.org
>
>> I'm not sure I see how this helps. That probably means I'm not considering
>> the right scenario. Could you elaborate on when having multiple hardware
>> queues to choose from a given CPU will provide a benefit?
>
> No, I do not keep in mind any particular scenario besides common
> sense. Just an assumption deeper queues are better (in this RFC
> a virtual combined queue consisting of multipe h/w queues).
>
> Apparently, there could be positive effects only in systems where
> # of queues / # of CPUs > 1 or # of queues / # of cores > 1. But
> I do not happen to have ones. If I had numbers this would not be
> the RFC and I probably would not have posted in the first place ;)
>
> Would it be possible to give it a try on your hardware?

Hello Alexander,

It is your task to measure the performance impact of these patches and 
not Keith's task. BTW, I'm not convinced that multiple hardware queues 
per CPU will result in a performance improvement. I have not yet seen 
any SSD for which a queue depth above 512 results in better performance 
than queue depth equal to 512. Which applications do you think will 
generate and sustain a queue depth above 512? Additionally, my 
experience from another high performance context (RDMA) is that reducing 
the number of queues can result in higher IOPS due to fewer interrupts 
per I/O.

Bart.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH RFC 00/21] blk-mq: Introduce combined hardware queues Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 13/21] blk-mq: Move hardware context init code into blk_mq_init_hctx() Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH RFC 19/21] blk-mq: Enable combined hardware queues Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 11/21] blk-mq: Move duplicating code to blk_mq_exit_hctx() Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 09/21] blk-mq: Cleanup a loop exit condition Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 08/21] blk-mq: Cleanup hardware context data node selection Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 21/21] null_blk: Do not limit # of hardware queues to # of CPUs Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH RFC 18/21] blk-mq: Enable tag numbers exceed hardware queue depth Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 14/21] blk-mq: Rework blk_mq_init_hctx() function Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 01/21] blk-mq: Fix memory leaks on a queue cleanup Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 15/21] blk-mq: Pair blk_mq_hctx_kobj_init() with blk_mq_hctx_kobj_put() Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 04/21] blk-mq: Do not limit number of queues to 'nr_cpu_ids' in allocations Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH 06/21] block: Remove redundant blk_mq_ops::map_queue() interface Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  [PATCH RFC 17/21] blk-mq: Introduce a 1:N hardware contexts Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 11:00 +0200
  Re: [PATCH RFC 00/21] blk-mq: Introduce combined hardware queues Christoph Hellwig <hch@infradead.org> - 2016-09-16 11:30 +0200
    Re: [PATCH RFC 00/21] blk-mq: Introduce combined hardware queues Alexander Gordeev <agordeev@redhat.com> - 2016-09-16 12:10 +0200
  Re: [PATCH RFC 00/21] blk-mq: Introduce combined hardware queues Keith Busch <keith.busch@intel.com> - 2016-09-16 23:00 +0200
    Re: [PATCH RFC 00/21] blk-mq: Introduce combined hardware queues Alexander Gordeev <agordeev@redhat.com> - 2016-09-19 12:40 +0200
      Re: [PATCH RFC 00/21] blk-mq: Introduce combined hardware queues Bart Van Assche <Bart.VanAssche@sandisk.com> - 2016-09-19 15:50 +0200
      Re: [PATCH RFC 00/21] blk-mq: Introduce combined hardware queues Keith Busch <keith.busch@intel.com> - 2016-09-20 16:50 +0200

csiph-web