[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.022 / U:12.708 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site