From: Nitesh Narayan Lal <nitesh@redhat.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs
Date: Mon, 19 Oct 2020 10:25:14 -0400 [thread overview]
Message-ID: <48a2a9a1-d664-6770-e088-27a7786e0f7b@redhat.com> (raw)
In-Reply-To: <20201019140005.GB17287@fuller.cnet>
On 10/19/20 10:00 AM, Marcelo Tosatti wrote:
> On Mon, Oct 19, 2020 at 01:11:37PM +0200, Peter Zijlstra wrote:
>> On Sun, Oct 18, 2020 at 02:14:46PM -0400, Nitesh Narayan Lal wrote:
[...]
>>>> Also, do we really need to have that conditional on hk_cpus <
>>>> num_online_cpus()? That is, why can't we do this unconditionally?
>>> FWIU most of the drivers using this API already restricts the number of
>>> vectors based on the num_online_cpus, if we do it unconditionally we can
>>> unnecessary duplicate the restriction for cases where we don't have any
>>> isolated CPUs.
>> unnecessary isn't really a concern here, this is a slow path. What's
>> important is code clarity.
Right, I can skip that check then.
>>
>>> Also, different driver seems to take different factors into consideration
>>> along with num_online_cpus while finding the max_vecs to request, for
>>> example in the case of mlx5:
>>> MLX5_CAP_GEN(dev, num_ports) * num_online_cpus() +
>>> ?????????????? MLX5_EQ_VEC_COMP_BASE
>>>
>>> Having hk_cpus < num_online_cpus() helps us ensure that we are only
>>> changing the behavior when we have isolated CPUs.
>>>
>>> Does that make sense?
>> That seems to want to allocate N interrupts per cpu (plus some random
>> static amount, which seems weird, but whatever). This patch breaks that.
> On purpose. For the isolated CPUs we don't want network device
> interrupts (in this context).
>
>> So I think it is important to figure out what that driver really wants
>> in the nohz_full case. If it wants to retain N interrupts per CPU, and
>> only reduce the number of CPUs, the proposed interface is wrong.
> It wants N interrupts per non-isolated (AKA housekeeping) CPU.
> Zero interrupts for isolated interrupts.
Right, otherwise we may end up in a situation where we run out of per CPU
vectors while we move the IRQs from isolated CPUs to housekeeping.
--
Thanks
Nitesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20201019/c70b8a10/attachment-0001.asc>
next prev parent reply other threads:[~2020-10-19 14:25 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 18:35 [Intel-wired-lan] [PATCH v4 0/4] isolation: limit msix vectors to housekeeping CPUs Nitesh Narayan Lal
2020-09-28 18:35 ` [Intel-wired-lan] [PATCH v4 1/4] sched/isolation: API to get number of " Nitesh Narayan Lal
2020-09-28 18:35 ` [Intel-wired-lan] [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 ` [Intel-wired-lan] [PATCH v4 3/4] i40e: Limit msix vectors to housekeeping CPUs Nitesh Narayan Lal
2020-09-28 18:35 ` [Intel-wired-lan] [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 [this message]
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
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 ` [Intel-wired-lan] [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=48a2a9a1-d664-6770-e088-27a7786e0f7b@redhat.com \
--to=nitesh@redhat.com \
--cc=intel-wired-lan@osuosl.org \
/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