Re: [PATCH v2] test: Update the threshold value for some perf tests

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

On Mon, Oct 13, 2025 at 12:24:37PM +0200, Stefano Brivio wrote:
> On Mon, 13 Oct 2025 15:39:32 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Mon, Oct 13, 2025 at 09:31:41AM +0800, Yumei Huang wrote:
> > > The values are adjusted to better match results observerd on the
> > > test hardware with 56-core Xeon Gold 6330 CPU and 126 GB RAM.  
> > 
> > Interesting.  That CPU is older than the one on my laptop (i7-12800H),
> > which comfortably hit the old thresholds, but by less than a year (Q2
> > 2021 versus Q1 2022).  At the same time it's a much fancier model for
> > its generation.  I thought the Xeons might have been built with better
> > memory bandwidth which probably has more effect on passt than the
> > CPU's computational speed.
> > 
> > I'm not certain what machine Stefano was using to estimate the
> > existing thresholds, but I'm guessing it was passt.top which is an AMD
> > Ryzen 5 3600 - older than both of the above (2019).
> 
> Yep.
> 
> > passt is single threaded so the Xeon's many cores wouldn't help it,
> > but it's still surprising that it can't keep up with the other
> > machines we've tried on.
> 
> Kernels and LSMs might make a huge difference as well. I expect a
> substantial system call overhead (because that's what it is here,
> I guess?) might come from SELinux hooks.

Ah, good point.

> Not that it really matters, I think, as long as numbers are reasonable
> (and we don't make them worse with some unsuspecting change) I don't see
> an actual problem with it.

That makes sense.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]