From: Colin Ian King <colin.king@canonical.com>
To: Tyler Hicks <tyhicks@canonical.com>
Cc: ecryptfs@vger.kernel.org,
Dustin Kirkland <dustin.kirkland@gazzang.com>,
Tim Chen <tim.c.chen@intel.com>,
Ying Huang <ying.huang@intel.com>, Thieu Le <thieule@google.com>,
Li Wang <dragonylffly@163.com>,
Zeev Zilberman <zeev@annapurnaLabs.com>,
Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
Subject: Re: [RFC v3 1/1] eCryptfs: Use the ablkcipher crypto API
Date: Wed, 10 Apr 2013 18:26:57 +0100 [thread overview]
Message-ID: <5165A0E1.3000306@canonical.com> (raw)
In-Reply-To: <1365534479-13202-1-git-send-email-tyhicks@canonical.com>
On 09/04/13 20:07, Tyler Hicks wrote:
> Make the switch from the blkcipher kernel crypto interface to the
> ablkcipher interface.
>
> encrypt_scatterlist() and decrypt_scatterlist() now use the ablkcipher
> interface but, from the eCryptfs standpoint, still treat the crypto
> operation as a synchronous operation. They submit the async request and
> then wait until the operation is finished before they return. Most of
> the changes are contained inside those two functions.
>
> Despite waiting for the completion of the crypto operation, the
> ablkcipher interface provides performance increases in most cases when
> used on AES-NI capable hardware. However, sequential I/O with one or two
> threads on slow storage media does exhibit a sizeable decrease in
> performance.
>
With the testing I've run with the ablkcipher patch I observe a
noticeable performance win with fast media such as SSD or tmpfs and a
slight improvement with fast 7200 rpm HDDs. With slower HDDs, I don't
see any negative performance impact with ablkcipher. Exercised on a
recent AES-NI capable Intel 4 core server with 7200 rpm HDD and Intel
330 SSD and also with a Intel i3-2350M Lenovo X220i laptop with a 5400
rpm HDD and Intel 330 SSD.
I have also given this patch considerable amount of soak testing
overnight with continuous parallel kernel builds while also running the
eCryptfs tests without any issues.
As it stands, I am happy with v3 of this patch.
next prev parent reply other threads:[~2013-04-10 17:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-05 23:42 [RFC 0/1] eCryptfs: Use the ablkcipher crypto API Tyler Hicks
2013-04-05 23:42 ` [RFC 1/1] " Tyler Hicks
2013-04-09 4:30 ` Tyler Hicks
2013-04-09 4:39 ` [RFC v2 " Tyler Hicks
2013-04-09 19:07 ` [RFC v3 " Tyler Hicks
2013-04-10 17:08 ` Tyler Hicks
2013-04-10 17:26 ` Colin Ian King [this message]
2013-04-28 7:37 ` Zeev Zilberman
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=5165A0E1.3000306@canonical.com \
--to=colin.king@canonical.com \
--cc=dragonylffly@163.com \
--cc=dustin.kirkland@gazzang.com \
--cc=ecryptfs@vger.kernel.org \
--cc=jarkko.sakkinen@iki.fi \
--cc=thieule@google.com \
--cc=tim.c.chen@intel.com \
--cc=tyhicks@canonical.com \
--cc=ying.huang@intel.com \
--cc=zeev@annapurnaLabs.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 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.