From: Benjamin Meier <benjamin.meier70@gmail.com>
To: hch@lst.de
Cc: kbusch@kernel.org, kbusch@meta.com, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org, ming.lei@redhat.com,
tglx@linutronix.de
Subject: Re: [PATCH 2/2] nvme-pci: allow unmanaged interrupts
Date: Mon, 13 May 2024 09:33:27 +0200 [thread overview]
Message-ID: <26d4ad30-c0fe-4286-9802-aa6afbd8074a@gmail.com> (raw)
In-Reply-To: <20240510151047.GA10486@lst.de>
> From: Christoph Hellwig <hch@lst.de>
>
> So let them argue why. I'd rather have a really, really, really
> good argument for this crap, and I'd like to hear it from the horses
> mouth.
I reached out to Keith to explore the possibility of manually defining
which cores handle NVMe interrupts.
The application which we develop and maintain (in the company I work)
has very high requirements regarding latency. We have some isolated cores
and we run our application on those.
Our system is using kernel 5.4 which unfortunately does not support
"isolcpus=managed_irq". Actually, we did not even know about that
option, because we are focussed on kernel 5.4. It solves part
of our problem, but being able to specify where exactly interrupts
are running is still superior in our opinion.
E.g. assume the number of house-keeping cores is small, because we
want to have full control over the system. In our case we have threads
of different priorities where some get an exclusive core. Some other threads
share a core (or a group of cores) with other threads. Now we are still
happy to assign some interrupts to some of the cores which we consider as
"medium-priority". Due to the small number of non-isolated cores, it can
be tricky to assign all interrupts to those without a performance-penalty.
Given these requirements, manually specifying interrupt/core assignments
would offer greater flexibility and control over system performance.
Moreover, the proposed code changes appear minimal and have no
impact on existing functionalities.
next prev parent reply other threads:[~2024-05-13 7:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 14:14 [PATCH 1/2] genirq/affinity: remove rsvd check against minvec Keith Busch
2024-05-10 14:14 ` [PATCH 2/2] nvme-pci: allow unmanaged interrupts Keith Busch
2024-05-10 15:10 ` Christoph Hellwig
2024-05-10 16:20 ` Keith Busch
2024-05-10 23:50 ` Ming Lei
2024-05-11 0:41 ` Keith Busch
2024-05-11 0:59 ` Ming Lei
2024-05-12 6:35 ` Thomas Gleixner
2024-05-20 15:37 ` Christoph Hellwig
2024-05-20 20:34 ` Thomas Gleixner
2024-05-21 2:31 ` Ming Lei
2024-05-21 8:38 ` Thomas Gleixner
2024-05-21 10:06 ` Frederic Weisbecker
2024-05-13 7:33 ` Benjamin Meier [this message]
2024-05-13 8:39 ` Ming Lei
2024-05-13 8:59 ` Benjamin Meier
2024-05-13 9:25 ` Ming Lei
2024-05-13 12:33 ` Benjamin Meier
2024-05-13 13:12 ` Bart Van Assche
2024-05-10 15:15 ` [PATCH 1/2] genirq/affinity: remove rsvd check against minvec Ming Lei
2024-05-10 16:47 ` Keith Busch
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=26d4ad30-c0fe-4286-9802-aa6afbd8074a@gmail.com \
--to=benjamin.meier70@gmail.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=ming.lei@redhat.com \
--cc=tglx@linutronix.de \
/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