On 2017-05-07 19:30, Mike Belopuhov wrote:
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
Hi Mike,
Thanks for the info, and for your work on the AES implementation.
With that said, is there any chance that this issue could be solved
such that CPUs like mine (which lack AES-NI) won't become super slow?
I can always stop using softraid crypto or buy a new CPU, but I'd
like to avoid that :)
Michael Reed
