Date: Tue, 28 Jan 2020 22:06:39 +0000 From: bugzilla-noreply@freebsd.org To: geom@FreeBSD.org Subject: [Bug 242747] geli: AMD Epyc+GELI not using Hardware AES Message-ID: <bug-242747-14739-c3j46VhbFk@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-242747-14739@https.bugs.freebsd.org/bugzilla/> References: <bug-242747-14739@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242747 --- Comment #5 from Conrad Meyer <cem@freebsd.org> --- I suppose it's possible that the AES-NI (or SSE) intrinsics on Epyc are just slower. I wouldn't expect such a substantial difference, though. It's also interesting that Epyc reports AES-XTS support while Xeon does not= .=20 That suggests the Xeon is running a different (older) version of FreeBSD th= an the Eypc. Maybe that's just from installing CURRENT on the Epyc, but for apples-to-apples comparison I'd suggest running the same version. When you installed CURRENT, did you compile a GENERIC-NODEBUG kernel / defi= ne MALLOC_PRODUCTION for world? Or is this just a snapshot published on the freebsd ftp server? If the latter, it's a debugging-enabled kernel, which = will result in substantially higher sys time. --=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-242747-14739-c3j46VhbFk>