On 8 May 2017 at 01:04, <[email protected]> wrote: > Synopsis: softraid crypto performance regression >> Category: system >> Environment: >> > System : OpenBSD 6.1 > Details : OpenBSD 6.1-current (GENERIC.MP) #51: Sat May 6 > 12:01:40 MDT 2017 > [email protected]:/us > r/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >> Description: >> > The issue appeared after upgrading from the April 20th snapshot to > the May 6th one. For context, my whole disk is encrypted, as > described in the FAQ (https://www.openbsd.org/faq/faq14.html#softraidFDE); > see below for disklabel information. > > With the April 20th snapshot, disk performance was fine; but with > the May 6th snapshot everything is slow. For example, where before > it took ~5 seconds for Libreoffice to open, now it takes ~30 seconds. > > > How-To-Repeat: >> > These instructions assume that you have the same disk setup as me; see > below for my disklabel information. > 1. download OpenBSD 6.1 miniroot.fs > 2. dd it to a USB drive > 3. boot it > 4. when the OpenBSD installer prompt comes up, hit "s" for (S)hell > 5. configure the existing crypto volume: > # bioctl -c C -l /dev/sd0a softraid0 > (enter existing volume password) > (crypto volume now mounted on /dev/sd2*) > 6. mount a partition in the crypto volume: > # mount /dev/sd2k /mnt > # cd /mnt > 7. create a blob of random data: > # dd if=/dev/random of=random_data bs=1m count=512 > 8. test disk performance: > # for i in 1 2 3; do sync && time cp random_data test$i; done > 9. record results > 10. repeat from step 1, replacing the 6.1 miniroot.fs with the May 6th > snapshot miniroot.fs > 11. compare results > > Here's my results: > 6.1: 28.89s, 36.39s, 27.63s > May 6 snapshot: 2m12.01s, 2m16.31s, 2m30.47s > > I know that many commits occurred between 6.1's release and May 6, > so, if needed, I can bisect for the problem commit. Besides that, > let me know if you need more info. > > > Fix: >> > Not known. > > Hi,
You observe a decrease in performance because we've switched to a constant time machine independent AES implementation which is inherently slower than the T-table version. Users with CPUs supporting AES-NI are not affected by this since the AES-NI driver provides it's own constant time implementation. Regards, Mike
