[lkml]   [2010]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RESEND] x86/irq: assign vectors from numa_node
On Thu, 9 Dec 2010, Arthur Kepner wrote:

> (Resending with expanded cc list.)
> Several drivers (e.g., mlx4_core) do something similar to:
> err = pci_enable_msix(pdev, entries, num_possible_cpus());
> which takes us down this code path:
> pci_enable_msix
> native_setup_msi_irqs
> create_irq_nr
> __assign_irq_vector
> __assign_irq_vector() preferentially uses vectors from low-numbered
> CPUs. On a system with a large number (>256) CPUs this can result in
> a CPU running out of vectors, and subsequent attempts to assign an
> interrupt to that CPU will fail.
> The following patch prefers vectors from the node associated with the
> device (if the device is associated with a node). This should make it
> far less likely that a single CPU's vectors will be exhausted.

I'm not going to pretend that I know this code *at all*, but what you
wrote made me think, and I want to share my thoughts. Perhaps they are
useful, perhaps not.

Assigning to the CPU associated with a device sounds sane and sounds like
it will distribute things more. So far so good. But I can't help wondering
if it wouldn't be sane (besides doing this) to simply fall back to the
next higher CPU if the chosen one is exhausted (or wrap around to the
first one if we are already at the highest one)... So that we'll only fail
completely if *all* CPU's are exhausted..?

Jesper Juhl <>
Don't top-post
Plain text mails only, please.

 \ /
  Last update: 2010-12-10 00:51    [W:0.070 / U:0.300 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site