archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <>
To: Ming Lei <>
Cc: Sagi Grimberg <>, Long Li <>,
	"" <>,
	Nadolski Edmund <>,
	Keith Busch <>,
	Thomas Gleixner <>,
	Christoph Hellwig <>
Subject: Re: [PATCH V3 0/2] nvme-pci: check CQ after batch submission for Microsoft device
Date: Fri, 22 Nov 2019 21:58:36 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20191122214954.GB8700@ming.t460p>

On 11/22/19 2:49 PM, Ming Lei wrote:
> On Fri, Nov 22, 2019 at 02:04:52PM +0000, Jens Axboe wrote:
>> On 11/22/19 3:25 AM, Ming Lei wrote:
>>>> as that will still overload the one cpu that the interrupt handler was
>>>> assigned to.  A dumb fix would be a cpu mask for the threaded interrupt
>>> Actually one CPU is fast enough to handle several drive's interrupt handling.
>>> Also there is per-queue depth limit, and the interrupt flood issue in network
>>> can't be serious on storage.
>> This is true today, but it won't be true in the future. Lets aim for a
>> solution that's a little more future proof than just "enough today", if
>> we're going to make changes in this area.
> That should be a new feature for future hardware, and we don't know any
> performance details, and it can be hard to prepare for it now. Maybe
> such hardware or case never comes:

Oh it'll surely come, and maybe sooner than you think. My point is that
using "one CPU is fast enough to handle several drive interrupts" is
very shortsighted, and probably not even true today.

> - storage device has queue depth, which limits the max in-flight requests
> to be handled in each queue's interrupt handler.

Only if new requests aren't also coming in and completing while you are
doing that work.
> - Suppose such fast hardware comes, it isn't reasonable for them
> to support N:1 mapping(N is big).

Very true, in fact that's already pretty damn dumb today...

> - Also IRQ matrix has balanced interrupt handling loading already, that
> said most of times, one CPU is just responsible for handing one hw queue's
> interrupt. Even in Azure's case, 8 CPUs are mapped to one hw queue, but
> there is just several CPUs which is for responsible for at most 2 hw queues.
> So could we focus on now and fix the regression first?

As far as I could tell from the other message, sounds like they both
have broken interrupt coalescing? Makes it harder to care, honestly...

But yes, I think we should do something about this. This really isn't a
new issue, if a core gets overloaded just doing completions from
interrupts, we should punt the work. NAPI has been doing that for ages,
and the block layer also used to have support it, but nobody used it.
Would be a great idea to make a blk-mq friendly version of that, with
the kinds of IOPS and latencies in mind that we see today and in the
coming years. I don't think hacking around this in the nvme driver is a
very good way to go about it.

Jens Axboe

Linux-nvme mailing list

  reply	other threads:[~2019-11-22 21:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14  2:59 [PATCH V3 0/2] nvme-pci: check CQ after batch submission for Microsoft device Ming Lei
2019-11-14  2:59 ` [PATCH V3 1/2] nvme-pci: move sq/cq_poll lock initialization into nvme_init_queue Ming Lei
2019-11-14  2:59 ` [PATCH V3 2/2] nvme-pci: check CQ after batch submission for Microsoft device Ming Lei
2019-11-14  4:56   ` Keith Busch
2019-11-14  8:56     ` Ming Lei
2019-11-21  3:11 ` [PATCH V3 0/2] " Ming Lei
2019-11-21  6:14   ` Christoph Hellwig
2019-11-21  7:46     ` Ming Lei
2019-11-21 15:45       ` Keith Busch
2019-11-22  9:44         ` Ming Lei
2019-11-22  9:57           ` Christoph Hellwig
2019-11-22 10:25             ` Ming Lei
2019-11-22 14:04               ` Jens Axboe
2019-11-22 21:49                 ` Ming Lei
2019-11-22 21:58                   ` Jens Axboe [this message]
2019-11-22 22:30                     ` Ming Lei

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).