public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-pci@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-kernel@vger.kernel.org
Subject: Re: Support for multiple MSI
Date: Wed, 4 Mar 2009 15:26:17 -0700	[thread overview]
Message-ID: <20090304222617.GA21720@parisc-linux.org> (raw)
In-Reply-To: <m17i35z6fc.fsf@fess.ebiederm.org>

On Wed, Mar 04, 2009 at 06:52:39AM -0800, Eric W. Biederman wrote:
> Do we have any benchmarks anywhere that show that multiple msi support
> gains us something?

Yep.  I get a 1% performance gain when doing

dd if=/dev/sdb of=/dev/null bs=512 count=10000000 iflag=direct

This is less improvement than I had expected, and I'm trying to find out
why before I publish the rest of the code.

> The requirement to allocate a contiguous block of vector numbers worries
> me for the x86 implementation.  I don't like the idea of having to deal
> with allocations that can fail because of fragmentation.

Multiple MSI support can fail for any number of reasons, fragmentation
is only one of them.  Drivers just have to deal with it.

> The fact that we also can not honor the irq affinity properly for multiple
> msi also disturbs me.

That's an x86 limitation; powerpc can independently steer MSI.

> At a quick skim your patchset is only the generic code without a single
> architecture specific implementation so it appears you have not done the
> hard work on figuring out how to deal with multiple msi in the real
> world.

I think that's terribly unfair.  How dare you insinuate I have done no
testing of my code?  I've published code before that implements multiple
MSI for x86-64, and I've adapted that code to the current tree.  When I
have enough time to do so, I'm going to adapt it to Ingo's -tip and
publish it.  There will be many things to criticise in it which I'm sure
will make you happy.

> Given that msi-x does not have any of these issues without data to say
> that there is a true gain in supporting multi-msi I don't see the point
> of supporting it.

There are people who have implemented it in silicon, and there is evidence of
performance improvement with Linux and with other operating systems.
Just because you don't like its limitations on x86 is not a valid reason
to keep it out.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

      reply	other threads:[~2009-03-04 22:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-23 17:27 Support for multiple MSI Matthew Wilcox
2009-02-23 17:27 ` [PATCH 1/6] Rewrite MSI-HOWTO Matthew Wilcox
2009-02-24 20:00   ` Randy Dunlap
2009-02-24 20:28     ` Matthew Wilcox
2009-02-24 20:55       ` Randy Dunlap
2009-02-25  7:34       ` Sitsofe Wheeler
2009-02-27  6:15   ` Grant Grundler
2009-02-27 12:14     ` Matthew Wilcox
2009-03-01 23:46       ` Michael Ellerman
2009-03-02 20:33       ` Grant Grundler
2009-03-02 21:01         ` Matthew Wilcox
2009-02-23 17:27 ` [PATCH 2/6] PCI MSI: Replace 'type' with 'is_msix' Matthew Wilcox
2009-03-03  0:16   ` Michael Ellerman
2009-02-23 17:27 ` [PATCH 3/6] PCI MSI: msi_desc->dev is always initialised Matthew Wilcox
2009-02-23 17:28 ` [PATCH 4/6] PCI MSI: Use mask_pos instead of mask_base when appropriate Matthew Wilcox
2009-02-23 17:28 ` [PATCH 5/6] PCI MSI: Refactor interrupt masking code Matthew Wilcox
2009-03-03  0:16   ` Michael Ellerman
2009-03-16 21:01     ` Matthew Wilcox
2009-02-23 17:28 ` [PATCH 6/6] PCI MSI: Add support for multiple MSI Matthew Wilcox
2009-03-03  0:16   ` Michael Ellerman
2009-03-16 21:07     ` Matthew Wilcox
2009-03-04 14:52 ` Support " Eric W. Biederman
2009-03-04 22:26   ` Matthew Wilcox [this message]

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=20090304222617.GA21720@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=ebiederm@xmission.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.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