From: Arthur Kepner <akepner@sgi.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [RFC/PATCHv2] x86/irq: round-robin distribution of irqs to cpus w/in node
Date: Wed, 29 Sep 2010 10:19:41 -0700 [thread overview]
Message-ID: <20100929171941.GH3096@sgi.com> (raw)
In-Reply-To: <m1eicennfu.fsf@fess.ebiederm.org>
(Compendium reply to 2 emails.)
On Mon, Sep 27, 2010 at 05:17:07PM -0700, Eric W. Biederman wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>
> > On Mon, 27 Sep 2010, Arthur Kepner wrote:
> >
> ......
> The deep bug is that create_irq_nr allocates a vector (which it does
> because at the time there was no better way to mark an irq in use on
> x86). In the case of msi-x we really don't know the node that irq is
> going to be used on until we get a request irq. We simply know which
> node the device is on.
>
> If you want to see what is going follow the call trace looks like.
> pci_enable_msix
> arch_setup_msi_irqs
> create_irq_nr
>
> After pci_enable_msix is finished then the driver goes and makes all
> of the irqs per cpu irqs.
>
> There are goofy things that happen when hardware asks for 1 irq per cpu.
> But since msi can ask for up to 4096 irqs (assuming the hardware
> supports it) I can totally see putting all 256 of those irqs on a single
> cpu, before you go to user space and let user space or something
> reassign all of those irqs in a per cpu way.
>
Yes, that's exactly the problem. All of the vectors on the lowest
numbered CPUs get used. Any subsequent request for an interrupt on
one of the low numbered CPUs will fail.
> .....
On Tue, Sep 28, 2010 at 03:59:33AM -0700, Eric W. Biederman wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>
> > On Mon, 27 Sep 2010, Eric W. Biederman wrote:
> >> > On Mon, 27 Sep 2010, Arthur Kepner wrote:
> >> The deep bug is that create_irq_nr allocates a vector (which it does
> >> because at the time there was no better way to mark an irq in use on
> >> x86). In the case of msi-x we really don't know the node that irq is
> >> going to be used on until we get a request irq. We simply know which
> >> node the device is on.
> >
> > Bah. So the whole per node allocation business is completely useless
> > at this point.
>
> Probably.
Huh? No, the patch that started this thread spreads the irqs around
and avoids the problem of a single CPU's vectors all being consumed.
> ...
>
> Understood. It has taken a couple of years before this bug finally
> bit anyone waiting a release or two to get it fixed properly seems
> reasonable.
> ....
And so what are we to do in the meantime? At the moment we're
disabling MSIX, which is a pretty unattractive workaround.
--
Arthur
next prev parent reply other threads:[~2010-09-29 17:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-27 20:34 [RFC/PATCHv2] x86/irq: round-robin distribution of irqs to cpus w/in node Arthur Kepner
2010-09-27 20:46 ` Thomas Gleixner
2010-09-27 22:01 ` Arthur Kepner
2010-09-27 22:12 ` Thomas Gleixner
2010-09-28 0:17 ` Eric W. Biederman
2010-09-28 8:08 ` Thomas Gleixner
2010-09-28 10:59 ` Eric W. Biederman
2010-09-29 17:19 ` Arthur Kepner [this message]
2010-09-29 18:05 ` Thomas Gleixner
2010-10-17 10:44 ` Thomas Gleixner
2010-10-19 23:58 ` Arthur Kepner
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=20100929171941.GH3096@sgi.com \
--to=akepner@sgi.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.