Matthew Wilcox <[email protected]> writes:
> Currently, Linux supports multiple MSI-X interrupts per device, but only
> a single MSI interrupt. This patch series adds support to the generic
> PCI code for supporting multiple MSI interrupts. Architectures will
> need to add support for multiple MSIs, and I have a patch to do that for
> x86 (which needs some more work). Getting this patch series in first
> is important so we can start supporting this interface in drivers and
> architectures independently.
Do we have any benchmarks anywhere that show that multiple msi support
gains us something?
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.
The fact that we also can not honor the irq affinity properly for multiple
msi also disturbs me.
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.
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.
Eric
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."