linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ignat Korchagin <ignat@cloudflare.com>
To: agk@redhat.com, snitzer@redhat.com, dm-devel@redhat.com,
	dm-crypt@saout.de, linux-kernel@vger.kernel.org
Cc: Ignat Korchagin <ignat@cloudflare.com>, kernel-team@cloudflare.com
Subject: [RFC PATCH 0/1] dm-crypt excessive overhead
Date: Fri, 19 Jun 2020 17:41:31 +0100	[thread overview]
Message-ID: <20200619164132.1648-1-ignat@cloudflare.com> (raw)

This is a follow up from the long-forgotten [1], but with some more convincing
evidence. Consider the following script:

#!/bin/bash -e

# create 4G ramdisk
sudo modprobe brd rd_nr=1 rd_size=4194304

# create a dm-crypt device with NULL cipher on top of /dev/ram0
echo '0 8388608 crypt capi:ecb(cipher_null) - 0 /dev/ram0 0' | sudo dmsetup create eram0

# create a dm-crypt device with NULL cipher and custom force_inline flag
echo '0 8388608 crypt capi:ecb(cipher_null) - 0 /dev/ram0 0 1 force_inline' | sudo dmsetup create inline-eram0

# read all data from /dev/ram0
sudo dd if=/dev/ram0 bs=4k iflag=direct | sha256sum

# read the same data from /dev/mapper/eram0
sudo dd if=/dev/mapper/eram0 bs=4k iflag=direct | sha256sum

# read the same data from /dev/mapper/inline-eram0
sudo dd if=/dev/mapper/inline-eram0 bs=4k iflag=direct | sha256sum

This script creates a ramdisk (to eliminate hardware bias in the benchmark) and
two dm-crypt instances on top. Both dm-crypt instances use the NULL cipher
to eliminate potentially expensive crypto bias (the NULL cipher just uses memcpy
for "encyption"). The first instance is the current dm-crypt implementation from
5.8-rc1, the second is the dm-crypt instance with a custom new flag enabled from
the patch attached to this thread. On my VM (Debian in VirtualBox with 4 cores
on 2.8 GHz Quad-Core Intel Core i7) I get the following output (formatted for
better readability):

# plain ram0
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 21.2305 s, 202 MB/s
8479e43911dc45e89f934fe48d01297e16f51d17aa561d4d1c216b1ae0fcddca  -

# eram0 (current dm-crypt)
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 53.2212 s, 80.7 MB/s
8479e43911dc45e89f934fe48d01297e16f51d17aa561d4d1c216b1ae0fcddca  -

# inline-eram0 (patched dm-crypt)
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 21.3472 s, 201 MB/s
8479e43911dc45e89f934fe48d01297e16f51d17aa561d4d1c216b1ae0fcddca  -

As we can see, current dm-crypt implementation creates a significant IO
performance overhead (at least on small IO block sizes) for both latency and
throughput. We suspect offloading IO request processing into workqueues and
async threads is more harmful these days with the modern fast storage. I also
did some digging into the dm-crypt git history and much of this async processing
is not needed anymore, because the reasons it was added are mostly gone from the
kernel. More details can be found in [2] (see "Git archeology" section).

We have been running the attached patch on different hardware generations in
more than 200 datacentres on both SATA SSDs and NVME SSDs and so far were very
happy with the performance benefits.

[1]: https://www.spinics.net/lists/dm-crypt/msg07516.html
[2]: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

Ignat Korchagin (1):
  Add DM_CRYPT_FORCE_INLINE flag to dm-crypt target

 drivers/md/dm-crypt.c | 55 +++++++++++++++++++++++++++++++++----------
 1 file changed, 43 insertions(+), 12 deletions(-)

-- 
2.20.1


             reply	other threads:[~2020-06-19 16:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-19 16:41 Ignat Korchagin [this message]
2020-06-19 16:41 ` [RFC PATCH 1/1] Add DM_CRYPT_FORCE_INLINE flag to dm-crypt target Ignat Korchagin
2020-06-24  5:04   ` [dm-crypt] " Eric Biggers
2020-06-24  5:21     ` [dm-devel] " Damien Le Moal
2020-06-24  5:27       ` Eric Biggers
2020-06-24  6:46         ` Damien Le Moal
2020-06-24  7:24         ` Damien Le Moal
2020-06-24  7:49     ` Damien Le Moal
2020-06-24  8:24     ` Ignat Korchagin
2020-06-24 16:24       ` Eric Biggers
2020-06-24 17:00         ` Ignat Korchagin
2020-06-24  5:12   ` [dm-devel] " Damien Le Moal
2020-06-19 16:55 ` [RFC PATCH 0/1] dm-crypt excessive overhead Mike Snitzer
2020-06-19 18:39   ` Mikulas Patocka
2020-06-19 19:44     ` Ignat Korchagin
2020-06-20  1:23     ` Herbert Xu
2020-06-20 19:36       ` Mikulas Patocka
2020-06-20 21:02         ` Ignat Korchagin
2020-06-23 15:33       ` Mike Snitzer
2020-06-23 16:24         ` Ignat Korchagin
2020-06-24  0:23           ` Herbert Xu
2020-06-22  0:45   ` [dm-devel] " Damien Le Moal
2020-06-22  7:55     ` Ignat Korchagin
2020-06-22  8:08       ` Damien Le Moal
2020-06-23 15:01     ` Mike Snitzer
2020-06-23 15:07       ` Ignat Korchagin
2020-06-23 15:22         ` Mike Snitzer
2020-06-24  4:54           ` [dm-devel] " Damien Le Moal
2020-06-24  5:22             ` Mike Snitzer
2020-06-24  8:02               ` Ignat Korchagin
2020-06-24  4:28       ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200619164132.1648-1-ignat@cloudflare.com \
    --to=ignat@cloudflare.com \
    --cc=agk@redhat.com \
    --cc=dm-crypt@saout.de \
    --cc=dm-devel@redhat.com \
    --cc=kernel-team@cloudflare.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=snitzer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).