From: Keith Busch <kbusch@kernel.org>
To: "Derrick, Jonathan" <jonathan.derrick@intel.com>
Cc: "lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"helgaas@kernel.org" <helgaas@kernel.org>
Subject: Re: [PATCH 3/3] PCI: vmd: Use managed irq affinities
Date: Thu, 7 Nov 2019 05:27:12 +0900 [thread overview]
Message-ID: <20191106202712.GA32215@redsun51.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <0a4a4151b56567f3c8ca71a29a2e39add6e3bf77.camel@intel.com>
On Wed, Nov 06, 2019 at 08:14:41PM +0000, Derrick, Jonathan wrote:
> Yes that problem exists today
Not really, because we're currently using unamanged interrupts which
migrate to online CPUs. It's only the managed ones that don't migrate
because they have a unchangeable affinity.
> and this set limits the exposure as it's
> a rare case where you have a child NVMe device with fewer than 32
> vectors.
I'm deeply skeptical that is the case. Even the P3700 has only 31 IO
queues, yielding 31 vectors for IO services, so that already won't work
with this scheme.
But assuming you wanted to only use devices that have at least 32 IRQ
vectors, the nvme driver also allows users to carve those vectors up
into fully affinitized sets for different services (read vs. write is
the one the block stack supports), which would also break if alignment
to the parent device's IRQ setup is required.
next prev parent reply other threads:[~2019-11-06 20:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 11:40 [PATCH 0/3] PCI: vmd: Reducing tail latency by affining to the storage stack Jon Derrick
2019-11-06 11:40 ` [PATCH 1/3] PCI: vmd: Reduce VMD vectors using NVMe calculation Jon Derrick
2019-11-06 18:02 ` Keith Busch
2019-11-06 19:51 ` Derrick, Jonathan
2019-11-06 11:40 ` [PATCH 2/3] PCI: vmd: Align IRQ lists with child device vectors Jon Derrick
2019-11-06 18:06 ` Keith Busch
2019-11-06 20:14 ` Derrick, Jonathan
2019-11-06 11:40 ` [PATCH 3/3] PCI: vmd: Use managed irq affinities Jon Derrick
2019-11-06 18:10 ` Keith Busch
2019-11-06 20:14 ` Derrick, Jonathan
2019-11-06 20:27 ` Keith Busch [this message]
2019-11-06 20:33 ` Derrick, Jonathan
2019-11-18 10:49 ` Lorenzo Pieralisi
2019-11-18 16:43 ` Derrick, Jonathan
2019-11-07 9:39 ` [PATCH 0/3] PCI: vmd: Reducing tail latency by affining to the storage stack Christoph Hellwig
2019-11-07 14:12 ` Derrick, Jonathan
2019-11-07 15:37 ` hch
2019-11-07 15:40 ` Derrick, Jonathan
2019-11-07 15:42 ` hch
2019-11-07 15:47 ` Derrick, Jonathan
2019-11-11 17:03 ` hch
2022-12-23 2:33 ` Kai-Heng Feng
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=20191106202712.GA32215@redsun51.ssa.fujisawa.hgst.com \
--to=kbusch@kernel.org \
--cc=helgaas@kernel.org \
--cc=jonathan.derrick@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.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 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).