Inclusion into upstream kernel plans?

[KlavsKlavsen]

Hi guys,

This is a fantastic optimization on a very important part of the system.. Who doesn't use LUKS today :)
I haven't been able to find any mentioning of this patch on any of the kernel mailinglists :(

Whats the plans, for including this in the upstream kernel, so everyone can benefit?

[ignatk]

Hi,

As you can see the current approach is "all-or-nothing". That is: you either get complete inline behaviour or not. While it greatly improved our IO cache workload (with smaller IO block size), other synthetic benchmarks with larger IO block size (~>2MB) actually sometimes show worse results.

Secondly, the current approach is rather x86-specific, but upstream kernel needs something more generic, which would at least run on different architectures.

The plan forward is to try to profile specific parts of dev-mapper/dm-crypt stack in more detail and have better understanding at what introduces the most overhead to provide more meaningful commit messages for kernel maintainers with some backing data.

I would not be surprised, if the proposed here force_inline flag would turn into several flags, which tune different parts of the stack independently.

That said - if you found the patches useful we would appreciate if you could share some details about your IO workload.

[KlavsKlavsen]

I'll have to get back to you on that once I actually try it out.. But my most important workload would by ceph disks encrypted with luks/dmcrypt, so each pod in k8s can choose if they need encryption at rest or not for their data (given the huge performance impact it has).

[ignatk]

I have initiated the discussion with the upstream. You may follow https://lkml.org/lkml/2020/6/19/1934

[MrM40]

Thanks you for then efforts to improve the performance in the upstream, it's very valuable for all of us :-) :-) :-)

[EnderShadow]

I don't mean to ressurect this issue, but this is for anyone who stumbles across this in the future. As of kernel version 5.9, the changes have been upstreamed. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.9-rc1&id=39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877

[KlavsKlavsen]

Its sad its not run-time options (via /proc knob) - but one has to recompile the kernel.. becomes annoying with all the kernel upgrades that happens all the time :(

[ignatk]

Well, even with proc support you have to recompile at least once to get the code in the first place. Once you have the kernel with above flags, you can just enable/disable flags in runtime by manipulating dmsetup table ... | dmsetup reload and doing dmsetup suspend && dmsetup resume. See https://blog.cloudflare.com/speeding-up-linux-disk-encryption/ for examples.

[neitsab]

Hi, thank you very much for all your work. Is there a step-by-step howto available to make use of those changes? As an end-user I'm having a bit of a hard time understanding what needs to be done to benefit from them. Like how to specify the new flags while recompiling the kernel? And should we also compile the xtsproxy module from the repo since the dmsetup table examples rely on it?
Cheers

[ignatk]

What distribution are you using? Maybe it makes sense just to wait for the upstream changes to get propagated?

[neitsab]

Thanks for your quick answer! I'm using Archlinux with kernel 5.9.2, and I ask because I'm just provisioning a new machine with NVMe storage where the encryption speedup would be most appreciated, especially since I'll be transfering a lot of user data for the initial setup.

Maybe it makes sense just to wait for the upstream changes to get propagated?

So you mean that once we have kernel 5.9 we don't need to recompile as indicated in a previous comment? Nothing else is needed but the dmsetup table ... | dmsetup reload operation? The examples in the article used capi:xts-aes-xtsproxy-plain64 which wasn't part of the merged changes if I understand correctly.

What I am mainly trying to grasp is: how to make use of the added flags (DM_CRYPT_NO_READ_WORKQUEUE and DM_CRYPT_NO_WRITE_WORKQUEUE if I got that right). Is it during kernel compilation, module loading/dmsetup change or something else? But then what is the equivalent of the 1 force_inline used in the article for dmsetup table? Are they to be used in conjunction with xtsproxy module or can they be used independently?

Thanks

[ignatk]

So you mean that once we have kernel 5.9 we don't need to recompile as indicated in a previous comment?

I think so. xts-aes-xtsproxy-plain64 was not merged, but we don't have enough evidence to say it is actually useful. Many other people tested the change without it and it seems the main performance contributor are the new flags, not the xts module. In the end, if you do want to try it, I think there is no need to recompile the whole kernel, just compile the xts module against your current 5.9 kernel.

Are they to be used in conjunction with xtsproxy module or can they be used independently?

Yes, you can use the flags independently.

It seems you don't need to mess with dmsetup table ... anymore. Latest release of cryptsetup included support for these flags:

...
* Added support for new no_read/write_wrokqueue dm-crypt options (kernel 5.9).

  These performance options, introduced in kernel 5.9, configure dm-crypt
  to bypass read or write workqueues and run encryption synchronously.

  Use --perf-no_read_workqueue or --perf-no_write_workqueue cryptsetup arguments
  to use these dm-crypt flags.

  These options are available only for low-level dm-crypt performance tuning,
  use only if you need a change to default dm-crypt behavior.

  For LUKS2, these flags can be persistently stored in metadata with
  the --persistent option.
...

If you're on Archlinux there is a good chance you already have v2.3.4 available (yes, it is), so just use standard cryptsetup commands with --perf-no_read_workqueue and/or --perf-no_read_workqueue flags, when you LUKS-format your new NVMEs.

[neitsab]

Thank you very much, this is exactly the information I was looking for! I'll try that and report the results. Much appreciated.

[neitsab]

Preliminary results with ramfs confirm the speed gains:

modprobe brd rd_nr=1 rd_size=4194304
echo '0 8388608 crypt capi:ecb(cipher_null) - 0 /dev/ram0 0' | dmsetup create eram0
echo '0 8388608 crypt capi:ecb(cipher_null) - 0 /dev/ram0 0 1 no_read_workqueue no_write_workqueue' | dmsetup create inline-eram0
dd if=/dev/ram0 bs=4k iflag=direct | sha256sum
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 8.67908 s, 495 MB/s
875eee50d50ba51a3a31f7e275bdc04c1615844785c374cfe7ae6fc0c8014287  -
dd if=/dev/mapper/eram0 bs=4k iflag=direct | sha256sum
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 9.65908 s, 445 MB/s
875eee50d50ba51a3a31f7e275bdc04c1615844785c374cfe7ae6fc0c8014287  -
dd if=/dev/mapper/inline-eram0 bs=4k iflag=direct | sha256sum
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 8.70909 s, 493 MB/s
875eee50d50ba51a3a31f7e275bdc04c1615844785c374cfe7ae6fc0c8014287  -

Now I need to find a good IO benchmark example involving NVMe storage to see what the effect is.

Note: at first I tried to do the testing it with:

cryptsetup luksFormat /dev/ram0
<dd test ram0>
cryptsetup open /dev/ram0 eram0
<dd test eram0>
cryptsetup refresh --perf-no_read_workqueue --perf-no_write_workqueue eram0
<dd test refreshed eram0>

The speed gains were exactly the same as in the previous examples, however the two sha256sums of eram0 did not match the one from ram0 (but were consistent together before/after refreshing with the perf parameters).

Edit: maybe this results from not using a detached header and overwriting it? From the article:

Those who are familiar with LUKS/dm-crypt might have noticed we used a LUKS detached header here. Normally, LUKS stores the password-encrypted disk encryption key on the same disk as the data, but since we want to compare read/write performance between encrypted and unencrypted devices, we might accidentally overwrite the encrypted key during our benchmarking later. Keeping the encrypted key in a separate file avoids this problem for the purposes of this post.

[ignatk]

Edit: maybe this results from not using a detached header and overwriting it? From the article:

This and the fact that with cryptsetup you're probably not using capi:ecb(cipher_null) anymore, but some proper encryption, most likely xts-aes-plain64.

So by hashing ram0 you're hashing raw (encrypted) data, but by hashing eram0 you're hashing plaintext (unencrypted) data.