Date: Tue, 28 Jan 2020 21:52:30 +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-TxVJ1oMNTW@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 #4 from Nick Evans <nevans@talkpoint.com> --- Epyc: aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS,SHA1,SHA256> Xeon: aesni0: <AES-CBC,AES-XTS,AES-GCM,AES-ICM> on motherboard Working on getting the GELI specific numbers. The long and short of it is i= f I dd from all 8 geli providers to /dev/null I see the same general results. 20-25% idle on the Epyc box, and 60-70% idle on the Xeon with the Epyc push= ing slightly more from each drive (~280 MB/s Epyc vs 250MB/s Xeon). I was seeing some weird performance results when doing dd tests against single drives or when testing multiple drives when ZFS is in the mix. From benchmarks of the= two CPUs these systems should be nearly identical for most tasks. I'm going to = sync the -CURRENT versions now and review the setups again to be sure nothing changed on me. I should have something in a few days. --=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-TxVJ1oMNTW>