All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.