From: Thomas Gleixner <tglx@linutronix•de>
To: Nitesh Narayan Lal <nitesh@redhat•com>,
linux-kernel@vger•kernel.org, netdev@vger•kernel.org,
linux-pci@vger•kernel.org, intel-wired-lan@lists•osuosl.org,
frederic@kernel•org, mtosatti@redhat•com, sassmann@redhat•com,
jesse.brandeburg@intel•com, lihong.yang@intel•com,
helgaas@kernel•org, jeffrey.t.kirsher@intel•com,
jacob.e.keller@intel•com, jlelli@redhat•com, hch@infradead•org,
bhelgaas@google•com, mike.marciniszyn@intel•com,
dennis.dalessandro@intel•com, thomas.lendacky@amd•com,
jiri@nvidia•com, mingo@redhat•com, peterz@infradead•org,
juri.lelli@redhat•com, vincent.guittot@linaro•org,
lgoncalv@redhat•com
Subject: Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs
Date: Tue, 20 Oct 2020 20:07:23 +0200 [thread overview]
Message-ID: <87lfg093fo.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <3bca9eb1-a318-1fc6-9eee-aacc0293a193@redhat.com>
On Tue, Oct 20 2020 at 12:18, Nitesh Narayan Lal wrote:
> On 10/20/20 10:16 AM, Thomas Gleixner wrote:
>> With the above change this will result
>>
>> 1 general interrupt which is free movable by user space
>> 1 managed interrupts (possible affinity to all 16 CPUs, but routed
>> to housekeeping CPU as long as there is one online)
>>
>> So the device is now limited to a single queue which also affects the
>> housekeeping CPUs because now they have to share a single queue.
>>
>> With larger machines this gets even worse.
>
> Yes, the change can impact the performance, however, if we don't do that we
> may have a latency impact instead. Specifically, on larger systems where
> most of the CPUs are isolated as we will definitely fail in moving all of the
> IRQs away from the isolated CPUs to the housekeeping.
For non managed interrupts I agree.
>> So no. This needs way more thought for managed interrupts and you cannot
>> do that at the PCI layer.
>
> Maybe we should not be doing anything in the case of managed IRQs as they
> are anyways pinned to the housekeeping CPUs as long as we have the
> 'managed_irq' option included in the kernel cmdline.
Exactly. For the PCI side this vector limiting has to be restricted to
the non managed case.
>> Only the affinity spreading mechanism can do
>> the right thing here.
>
> I can definitely explore this further.
>
> However, IMHO we would still need a logic to prevent the devices from
> creating excess vectors.
Managed interrupts are preventing exactly that by pinning the interrupts
and queues to one or a set of CPUs, which prevents vector exhaustion on
CPU hotplug.
Non-managed, yes that is and always was a problem. One of the reasons
why managed interrupts exist.
Thanks,
tglx
next prev parent reply other threads:[~2020-10-20 18:07 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 18:35 [PATCH v4 0/4] isolation: limit msix vectors to housekeeping CPUs Nitesh Narayan Lal
2020-09-28 18:35 ` [PATCH v4 1/4] sched/isolation: API to get number of " Nitesh Narayan Lal
2020-09-28 18:35 ` [PATCH v4 2/4] sched/isolation: Extend nohz_full to isolate managed IRQs Nitesh Narayan Lal
2020-10-23 13:25 ` Peter Zijlstra
2020-10-23 13:29 ` Frederic Weisbecker
2020-10-23 13:57 ` Nitesh Narayan Lal
2020-10-23 13:45 ` Nitesh Narayan Lal
2020-09-28 18:35 ` [PATCH v4 3/4] i40e: Limit msix vectors to housekeeping CPUs Nitesh Narayan Lal
2020-09-28 18:35 ` [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() " Nitesh Narayan Lal
2020-09-28 21:59 ` Bjorn Helgaas
2020-09-29 17:46 ` Christoph Hellwig
2020-10-16 12:20 ` Peter Zijlstra
2020-10-18 18:14 ` Nitesh Narayan Lal
2020-10-19 11:11 ` Peter Zijlstra
2020-10-19 14:00 ` Marcelo Tosatti
2020-10-19 14:25 ` Nitesh Narayan Lal
2020-10-20 7:30 ` Peter Zijlstra
2020-10-20 13:00 ` Nitesh Narayan Lal
2020-10-20 13:41 ` Peter Zijlstra
2020-10-20 14:39 ` Nitesh Narayan Lal
2020-10-22 17:47 ` Nitesh Narayan Lal
2020-10-23 8:58 ` Peter Zijlstra
2020-10-23 13:10 ` Nitesh Narayan Lal
2020-10-23 21:00 ` Thomas Gleixner
2020-10-26 13:35 ` Nitesh Narayan Lal
2020-10-26 13:57 ` Thomas Gleixner
2020-10-26 17:30 ` Marcelo Tosatti
2020-10-26 19:00 ` Thomas Gleixner
2020-10-26 19:11 ` Marcelo Tosatti
2020-10-26 19:21 ` Jacob Keller
2020-10-26 20:11 ` Thomas Gleixner
2020-10-26 21:11 ` Jacob Keller
2020-10-26 21:50 ` Thomas Gleixner
2020-10-26 22:13 ` Jakub Kicinski
2020-10-26 22:46 ` Thomas Gleixner
2020-10-26 22:52 ` Jacob Keller
2020-10-26 22:22 ` Nitesh Narayan Lal
2020-10-26 22:49 ` Thomas Gleixner
2020-10-26 23:08 ` Jacob Keller
2020-10-27 14:28 ` Thomas Gleixner
2020-10-27 11:47 ` Marcelo Tosatti
2020-10-27 14:43 ` Thomas Gleixner
2020-10-19 14:21 ` Frederic Weisbecker
2020-10-20 14:16 ` Thomas Gleixner
2020-10-20 16:18 ` Nitesh Narayan Lal
2020-10-20 18:07 ` Thomas Gleixner [this message]
2020-10-21 20:25 ` Thomas Gleixner
2020-10-21 21:04 ` Nitesh Narayan Lal
2020-10-22 0:02 ` Jakub Kicinski
2020-10-22 0:27 ` Jacob Keller
2020-10-22 8:28 ` Thomas Gleixner
2020-10-22 12:28 ` Marcelo Tosatti
2020-10-22 22:39 ` Thomas Gleixner
2020-10-01 15:49 ` [PATCH v4 0/4] isolation: limit msix vectors " Frederic Weisbecker
2020-10-08 21:40 ` Nitesh Narayan Lal
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=87lfg093fo.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix$(echo .)de \
--cc=bhelgaas@google$(echo .)com \
--cc=dennis.dalessandro@intel$(echo .)com \
--cc=frederic@kernel$(echo .)org \
--cc=hch@infradead$(echo .)org \
--cc=helgaas@kernel$(echo .)org \
--cc=intel-wired-lan@lists$(echo .)osuosl.org \
--cc=jacob.e.keller@intel$(echo .)com \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=jesse.brandeburg@intel$(echo .)com \
--cc=jiri@nvidia$(echo .)com \
--cc=jlelli@redhat$(echo .)com \
--cc=juri.lelli@redhat$(echo .)com \
--cc=lgoncalv@redhat$(echo .)com \
--cc=lihong.yang@intel$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-pci@vger$(echo .)kernel.org \
--cc=mike.marciniszyn@intel$(echo .)com \
--cc=mingo@redhat$(echo .)com \
--cc=mtosatti@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nitesh@redhat$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=sassmann@redhat$(echo .)com \
--cc=thomas.lendacky@amd$(echo .)com \
--cc=vincent.guittot@linaro$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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