Date: Wed, 20 Jan 2021 00:14:04 +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-Mz3XS3tkpw@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 #29 from Alan Somers <asomers@FreeBSD.org> --- Yes, the default value of kern.geom.eli.threads only really makes sense if = you have 1-2 geli providers. If you have lots (I have hundreds), you should set kern.geom.eli.threads=3D1. I do have a WIP patch that would switch geli from using a per-provider thre= ad pool to a single global thread pool. That would eliminate the need to tune that sysctl, and improve overall performance to boot. However, the patch is held-up by an incompatibility with ccp(4). ccp is a hardware crypto device found on some AMD systems. I notice that you're using AMD. Does your syst= em have ccp? (I think it will show up as "AMD CCP" in `pciconf -lv`) And if s= o, would you be willing to help test changes? https://reviews.freebsd.org/D25747 --=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-Mz3XS3tkpw>