All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Lieven <pl@dlh.net>
To: linux-crypto@vger.kernel.org
Subject: kcryptd performance issues, write faster than read on raid0/lvm?!
Date: Mon, 03 Aug 2009 21:41:07 +0200	[thread overview]
Message-ID: <4A773D53.5040907@dlh.net> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Community,

I use an Atom 330 (Dual-Core) ION based system as work station at home.
The rootfs is crypted with cryptsetup/luks.

As the Atom 330 is rather weak in cryptographic speed and I realized that a single
blockdevice is always handled by only one kcryptd thread, I tried out a tweak
to spread the work to 2 CPU cores.

I have a volume group on the built-in SSD of the Nettop and I created two
equally-sized volumes. Each of the volumes is encrypted using cryptsetup.
When both volumes are succesfully unlocked they form a raid-0 device.
Since I work on an SSD this should not create a performance problem
due to high amount of seeks.

And here is what is totally strange:
When I read from this raid, I get a throughput of about 24MB/s (what is
about the amount an Atom Core @1.6GHz (aes_x86) can decrypt per second. Looking
at the 2 kcryptd processes I find that each is using nearly 50% cpu
time. As if they where running only on a single core and/or waiting
for each other?!

lieven@dozer64-ssd:~$ sh speedtest-read.sh
Sa 1. Aug 21:52:19 CEST 2009
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 43,661 s, 24,6 MB/s
Sa 1. Aug 21:53:03 CEST 2009

# 1024MB / 44 sec = 23,2 MB/sec

lieven@dozer64-ssd:~$ cat speedtest-read.sh
#!/bin/sh
sync
date
dd if=/home/lieven/speedtest.dat of=/dev/null bs=1M
sync
date

hdparm outputs about the same performance:
lieven@dozer64-ssd:~$ sudo hdparm -tT /dev/md0

/dev/md0:
 Timing cached reads:   1244 MB in  2.00 seconds = 621.48 MB/sec
 Timing buffered disk reads:   70 MB in  3.04 seconds =  23.01 MB/sec

But, when I write to /dev/md0 I get a significantly better performance:

lieven@dozer64-ssd:~$ sh speedtest-write.sh
Sa 1. Aug 22:19:04 CEST 2009
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 27,2655 s, 39,4 MB/s
Sa 1. Aug 22:19:36 CEST 2009

# 1024 MB / 32 sec = 32 MB / sec

lieven@dozer64-ssd:~$ cat speedtest-write.sh
#!/bin/sh
sync
date
dd if=/dev/zero of=/home/lieven/speedtest.dat bs=1M count=1024
sync
date

If I look at the both kcryptd processes I see that both are using
roughly 100% of one CPU core each when i write to /dev/md0.

Before I made this setup, I tried it on an unencrypted volume
with 2 files mounted via loop, crypted and then added to raid.
In this case, the read performance is as expected (about 45MB/s).

I tried with ubuntu jaunty kernel 2.6.28-13 and I also tried
2.6.30.4 as I read about the kcrypt workqueue patch that was
added recently.

Does anyone have an explaination for this?

Thanks,
Peter




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkp3PVMACgkQO/ibohXUOnKYXQCcDrZ0qmnfsn+IkBoAmnEZXkVN
rWAAoL0NYiPYeawhMMP2zvbslftyhNeZ
=IfDQ
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

                 reply	other threads:[~2009-08-03 20:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4A773D53.5040907@dlh.net \
    --to=pl@dlh.net \
    --cc=linux-crypto@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.