From: Alexander Gordeev <agordeev@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Joerg Roedel <joro@8bytes.org>, "x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
Jan Beulich <JBeulich@suse.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linuxppc-dev@lists.ozlabs.org, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
Date: Thu, 26 Sep 2013 09:46:46 +0200 [thread overview]
Message-ID: <20130926074646.GA16774@dhcp-26-207.brq.redhat.com> (raw)
In-Reply-To: <20130925210016.GA8926@htj.dyndns.org>
On Wed, Sep 25, 2013 at 05:00:16PM -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 25, 2013 at 10:58:05PM +0200, Alexander Gordeev wrote:
> > Unfortunately, pSeries is a shows-topper here :( It seems we have to
> > introduce pci_get_msi{,x}_limit() interfaces to honour the quota
> > thing. I just hope the hardware set for pSeries is limited and we
> > won't need to use it for all drivers.
>
> Can you please go into a bit of detail on that? Why does it matter?
Because otherwise we will re-introduce a problem described by Michael:
"We have a small number of MSIs available, limited by hardware &
firmware, if we don't impose a quota then the first device that probes
will get most/all of the MSIs and other devices miss out."
> Is it because you're worried you might cause performance regression by
> forcing prevoius partial multiple allocations to single interrupt
> operation?
Well, not really. I think it won't be possible to force people not to use
partial allocations anyway. Some controllers just do not care how many MSIs
they are configured with. Some drivers derive the number of MSIs desired
from the number of CPUs online - in such cases allocating more MSIs (i.e.
a number the controller advertised) could cause a performance degradation
even.
So when driver authors will know/measure/believe their hardware performs
better with partial allocations they will stand for it. What we can do is
to prevent those try-and-decrease fallbacks.
> Thanks.
>
> --
> tejun
--
Regards,
Alexander Gordeev
agordeev@redhat.com
next prev parent reply other threads:[~2013-09-26 7:44 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130905150259.GA30984@dhcp-26-207.brq.redhat.com>
[not found] ` <20130905150442.GA24148@htj.dyndns.org>
[not found] ` <20130905154041.GD30984@dhcp-26-207.brq.redhat.com>
[not found] ` <20130905154436.GC24148@htj.dyndns.org>
[not found] ` <20130905185440.GA13175@dhcp-26-207.brq.redhat.com>
[not found] ` <20130905200608.GA3846@htj.dyndns.org>
[not found] ` <CAErSpo4TU2geqzY3AYsL08KimBqtfwa4iUoFHgcFt0zMTBJkHw@mail.gmail.com>
[not found] ` <20130906160621.GF22763@mtj.dyndns.org>
[not found] ` <20130906233205.GF12956@google.com>
[not found] ` <20130909152044.GA24962@dhcp-26-207.brq.redhat.com>
2013-09-16 10:22 ` [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface Alexander Gordeev
2013-09-17 14:30 ` Michael Ellerman
2013-09-18 9:48 ` Alexander Gordeev
2013-09-18 14:22 ` Tejun Heo
2013-09-18 16:50 ` Alexander Gordeev
2013-09-20 8:24 ` Alexander Gordeev
2013-09-20 12:27 ` Tejun Heo
2013-09-25 18:02 ` Bjorn Helgaas
2013-09-25 20:58 ` Alexander Gordeev
2013-09-25 21:00 ` Tejun Heo
2013-09-26 7:46 ` Alexander Gordeev [this message]
2013-09-26 8:58 ` David Laight
2013-09-26 10:45 ` Alexander Gordeev
2013-09-26 11:34 ` David Laight
2013-09-26 12:13 ` Alexander Gordeev
2013-09-26 13:11 ` Tejun Heo
2013-09-26 14:39 ` Alexander Gordeev
2013-09-26 14:42 ` Tejun Heo
2013-10-01 7:19 ` Michael Ellerman
2013-09-20 12:26 ` Tejun Heo
2013-10-01 7:26 ` Michael Ellerman
2013-10-01 7:35 ` Michael Ellerman
2013-10-01 11:55 ` Tejun Heo
2013-10-02 2:33 ` Michael Ellerman
2013-10-02 3:23 ` Tejun Heo
2013-09-26 12:32 ` Mark Lord
2013-09-26 13:03 ` Alexander Gordeev
2013-10-02 2:46 ` Mark Lord
2013-10-02 7:26 ` Alexander Gordeev
2013-12-18 18:26 ` Bjorn Helgaas
2013-10-01 7:51 ` Michael Ellerman
2013-10-01 10:35 ` Alexander Gordeev
2013-10-02 2:43 ` Michael Ellerman
2013-10-02 7:10 ` Alexander Gordeev
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=20130926074646.GA16774@dhcp-26-207.brq.redhat.com \
--to=agordeev@redhat.com \
--cc=JBeulich@suse.com \
--cc=bhelgaas@google.com \
--cc=joro@8bytes.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@kernel.org \
--cc=tj@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).