archive mirror
 help / color / mirror / Atom feed
From: "Kristóf Csillag" <>
Subject: performance and threads
Date: Mon, 5 Sep 2022 05:52:06 +0200	[thread overview]
Message-ID: <> (raw)

Dear all,

I would like to ask you if what I am seeing is normal, or it's some
configuration problem.

Short summary: reading my encrypted is a lot slower than reading it
raw, while the CPU is underutilized.

Detailed version:

I have a RAID1 device, consisting of two identical NVMe devices.
On the top of the RAID device, I have LUKS encryption.

These are the read speeds:

- Raw device read: 2,3 GB/s
- RAID device read: 2,3 GB/s
- Reading from the encrypted device: 1,6 GB/s

As you can see, there is a pretty serious performance penalty for the
The cipher running is the default aes-xts-plain64 cipher.
This is an AMD Ryzen 9 5900X 12-Core CPU, so I'm not sure what this is.
What is even more interesting, is that the CPU doesn't seem to be all
that busy during the reading. as far as I can tell, I only get 4
threads of kworker / kcryptd, and their total system load is less than
100% (of 1 core.)

So I'm getting the impression that even though decryption is a
CPU-bound process, my CPU is still underutilized.

Is this interpretation correct? If yes, is this to be expected, or am
I doing something wrong? Can dm-crypt be configured to run the
encryption on more CPU cores, with better performance?

Thank you for your help:

    Kristof Csillag

ps. I'm on kernel 5.19

             reply	other threads:[~2022-09-05  3:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05  3:52 Kristóf Csillag [this message]
2022-09-05  6:34 ` performance and threads Michael Kjörling
2022-09-05 15:09 ` Arno Wagner
2022-09-15 14:55 ` Milan Broz

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:

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

  git send-email \ \ \ \

* 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).