Date: Thu, 09 Nov 2023 17:53:33 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 274994] Regression of iperf3 network throughput tests with erms "rep movsb" copyto loops Message-ID: <bug-274994-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274994 Bug ID: 274994 Summary: Regression of iperf3 network throughput tests with erms "rep movsb" copyto loops Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: rscheff@freebsd.org Initially, the thinking was, that a missing patch 6210ac95a194 was responsi= ble, but even with=20 that patch, the below results are reproducable; The exclusion of the erms codepath was performed by patching copyout.c like= so - thus only the copyin smap_std or copyin_nosmap_std would be used; however, smap is disabled elsewhere too, thus this collapses to a comparison between copyin_nosmap_std and copyin_nosmap_erms: > switch (cpu_stdext_feature & (CPUID_STDEXT_SMAP | CPUID_STDEXT_ER= MS)) { > case CPUID_STDEXT_SMAP: > return (copyin_smap_std); > + #if 0 > case CPUID_STDEXT_ERMS: > return (copyin_nosmap_erms); > case CPUID_STDEXT_SMAP | CPUID_STDEXT_ERMS: > return (copyin_smap_erms); > + #else=20 > + case CPUID_STDEXT_SMAP | CPUID_STDEXT_ERMS: > + return (copyin_smap_std); > #endif=20 > default: > return (copyin_nosmap_std); > } On Sapphire Rapids Xeon Gold 5416S (processor ID 0x806f7) (4th Gen) with erms "rep movsb": > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 4] 0.00-20.00 sec 83.6 GBytes 35.9 Gbits/sec 0 sen= der > [ 4] 0.00-20.04 sec 83.6 GBytes 35.9 Gbits/sec rec= eiver replacing the erms with no-smap,no-erms copyto: > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 4] 0.00-20.00 sec 86.7 GBytes 37.2 Gbits/sec 147 sen= der > [ 4] 0.00-20.04 sec 86.7 GBytes 37.2 Gbits/sec rec= eiver Xeon Gold 6438N (processor ID 0x806f7) (4th Gen)=20 with erms "rep movsb": - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 4] 0.00-20.00 sec 1.55 GBytes 664 Mbits/sec 0 sen= der > [ 4] 0.00-20.05 sec 1.54 GBytes 661 Mbits/sec rec= eiver replacing the erms with no-smap,no-erms copyto: > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 4] 0.00-20.00 sec 91.9 GBytes 39.5 Gbits/sec 0 sen= der > [ 4] 0.00-20.05 sec 91.9 GBytes 39.4 Gbits/sec rec= eiver On Ice Lake Xeon Platinum 8352Y (processor ID 0x606a6) (3rd Gen) with erms "rep movsb": > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 4] 0.00-20.00 sec 33.6 GBytes 14.5 Gbits/sec 0 sen= der > [ 4] 0.00-20.04 sec 33.6 GBytes 14.4 Gbits/sec rec= eiver replacing the erms with no-smap,no-erms copyto: > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 4] 0.00-20.00 sec 76.1 GBytes 32.7 Gbits/sec 0 sen= der > [ 4] 0.00-20.03 sec 76.1 GBytes 32.6 Gbits/sec rec= eiver >=20 Similar performance degradation was observed on many older platforms using = the erms codepath, and the iperf3 testing utility, with typical performance imp= act between 40-60%. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-274994-227>