Re: AMD EPYC virtual network performances

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Fri, Nov 15, 2024 at 07:46:07AM +0100, Jürgen Groß wrote:
> On 15.11.24 01:11, Elliott Mitchell wrote:
> > On Wed, Nov 13, 2024 at 08:20:02PM +0100, Jürgen Groß wrote:
> > > On 13.11.24 18:25, Elliott Mitchell wrote:
> > > > 
> > > > Hopefully I'm not making knave speculation here.  Might this be the
> > > > simplest of issues, just it was missed due to being too obvious?
> > > 
> > > I don't agree with your analysis, see above.
> > 
> > Okay.  I was asking since it looked a bit odd and there has been no news
> > on this issue (unless I missed some patch flying by).
> > 
> > I don't know how large the impact of this is.  I wouldn't be surprised if
> > this turned out to overwhelm all my other efforts at performance
> > improvement.
> > 
> > Any news on your efforts to track this down?
> 
> ENOTIME up to now.
> 
> Did you try to set the spurious threshold to e.g. 2 instead of the default
> of 1? In case that helps it might be a good idea to either change the default
> or to at least add a boot parameter for setting the default.

Appears it may somewhat, but not fully alleviate the situation.

Just to make sure this is stated.  The spurious events are being
observed on the back-ends of block and network devices.  The
corresponding front-ends aren't recording any spurious events.

I now wonder whether the network back-end I'm attempting to place in a
DomU will observe spurious events.


-- 
(\___(\___(\______          --=> 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