Re: AMD EPYC virtual network performances

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Wed, Jul 10, 2024 at 12:19:20PM -0700, Elliott Mitchell wrote:
> On Tue, Jul 09, 2024 at 08:36:18AM +0000, Andrei Semenov wrote:
> > 
> > Does anybody notice this behavior on his side?  Can we do something 
> > about it?
> 
> I hadn't previously noticed this manifestation, but now that I know where
> to look seems I'm also seeing the issue.
> 
> It also effects PVH domains, but may not have as much impact.
> 
> It also effects virtual block devices.
> 
> 
> Right now I consider this highly speculative, but I am now wondering
> whether the software RAID1 issue is related to this.

Having considered what I'm observing a bit more, this is pure
speculation; however, there is a rather severe situation to consider.

I now suspect most/all of the lines showing up in `xl dmesg` due to
iommu=debug are likely associated with the spurious interrupt issue, not
the RAID1 issue.  The result is iommu=debug is useless for attempting to
debug anything other than the spurious interrupt issue.  The messages
associated with the spurious interrupts are generating too much noise.

The spurious interrupt issue seems to be pretty severe.

In other news, appears iommu=no-intremap does not address the
software-RAID1 issue.  Could be it reduces performance sufficiently
to somewhat mitigate the issue though.

I am also looking attempting to track down one other issue which might
also mitigate this.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445