From: Jakob Sandgren <jakob@southpole.se>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Poor performane (idle cpu) [SOLVED; problem with "pv"]
Date: Tue, 9 Feb 2010 15:48:29 +0100 [thread overview]
Message-ID: <20100209144829.GA4211@southpole.se> (raw)
In-Reply-To: <20100209002806.GA14310@tansi.org>
On Tue, Feb 09, 2010 at 01:28:06AM +0100, Arno Wagner wrote:
> On Tue, Feb 09, 2010 at 12:54:16AM +0100, Jakob Sandgren wrote:
> > Hi,
> >
> > (please keep me on CC since I'm not subscribed yet)
> >
> > To me it seems like there is some serious flaw within kcryptd that
> > ends up to wait for "something" instead of sending enough requests to
> > the disks to make sure it has data to decrypt. What do you think?
>
> The same thing.
>
> Here is a reference test (I have notebook disks in this server):
>
> Raw read: 54MB/s 14% CPU
> Read with decrypt: 53MB/s 65% CPU
For reference this is the exact output of my benchmark, maybe there
are some difference in setup or benchmark?
OOOOOooops! While putting toghether this information I actually found
the cause of the problem, it was my benchark that was wrong!
This was the benchmark I used to get the performance was:
dd if=/dev/mapper/bench1 bs=4M iflag=direct |pv | dd of=/dev/null
and the number reported by "pv" during the run was ~75MB/s and dd
reported the same number when finished.
Changing this to:
dd if=/dev/mapper/bench1 bs=4M iflag=direct of=/dev/null count=1000
gave a more correct number; 125MB/s
I was not aware of that piping the data through pv would cause such a
big degradation in performance.
> That would mean the crypto is pretty slow on your new CPU.
> As a reference, my 53MB/s at 65% CPU is on an 2800MHz Athlon
> 64 X2 5600+ with aes-cbc-plain.
>
> Here is an OpenSSL crypto speed test:
> openssl speed -evp aes-256-cbc
> [...]
> The 'numbers' are in 1000s of bytes per second processed.
> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
> aes-256-cbc 71848.00k 98649.49k 110187.78k 113646.25k 114666.15k
>
> You might want to compare this with the numbers on your CPU.
The numbers from my system (Core I7) are below
root@mvh:~# openssl speed -evp aes-256-cbc
...
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 110769.28k 118629.67k 120600.15k 121138.86k 121206.10k
I has now been able to get a 175MB/sec from my main raid partition.
Best Regards,
Jakob
--
next prev parent reply other threads:[~2010-02-09 14:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-08 1:16 [dm-crypt] Poor performane (idle cpu) Jakob Sandgren
2010-02-08 1:50 ` Arno Wagner
2010-02-08 23:54 ` Jakob Sandgren
2010-02-09 0:28 ` Arno Wagner
2010-02-09 14:48 ` Jakob Sandgren [this message]
2010-02-09 16:14 ` [dm-crypt] Poor performane (idle cpu) [SOLVED; problem with "pv"] Arno Wagner
2010-02-09 16:16 ` M Thomas Frederiksen
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=20100209144829.GA4211@southpole.se \
--to=jakob@southpole.se \
--cc=dm-crypt@saout.de \
/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