[NCLUG] linux laptop

Bob Proulx bob at proulx.com
Thu Mar 24 22:59:34 MDT 2011


Maxwell Spangler wrote:
> Sean Reifschneider wrote:
> > Interesting...  I've been running dm_crypt on my laptop for 5
> > years or so and I can't remember the last time I noticed the
> > performance impact.  Even on the Pentium M 1.8GHz I used to have,
> > I just didn't notice the overhead of crypto.
> 
> I run it on a Pentium M 1.5GHz from 2004 -- can't tell the difference
> either.  I feel a lot better knowing that if my laptop gets stolen the
> data is inaccessable.

I also run a fully encrypted laptop filesystem.  It is easy to set up
using the Debian installer.  When I set this up way back in the days
of Etch I ran some benchmarks.  I was worried about the performance of
running an encrypted filesystem on a relatively low powered machine.
Since this came up in discussion I decided to dig this out of my
archive.

This is old data now but I still have it and so you might find it
interesting.  This was on a Thinkpad T42 Pentium M 735 1.7GHz with a
5400rpm 80G IDE disk.  I clamped the ram to 512M for this test so that
file sizes bonnie needed to avoid the buffer cache would not be too
large and would not take too long.  I installed Debian Etch for this
test.  Etch was current at that time.

Version  1.03      ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
none             1G 20813  62 21960   7  8210   2 17339  46 18144   2 126.0   0
aes128           1G 19247  56 22154   9  9358   2 18675  49 22030   2 135.2   0
aes256           1G 17252  50 27740  14 12110   2 14528  39 28246   3 141.8   0

In the first case no encryption was used.  I did use lvm because I
used lvm for the encrypted cases and this way all three went through
the lvm layer.  An lvm volume was created with a 4G logical volume for
swap and another logical volume of the rest for the root filesystem.

The second case used AES with 128 bit encryption with dm-crypt.  Then
an lvm volume was created using the encrypted partition with a 4G
logical volume for swap and the rest for the root filesystem.

The third case used AES 256 bit encryption but was otherwise identical
to the second case.  I expected this to be the slowest case since it
had the strongest encryption.  Counter to what I expected it was
faster in some cases.  Block sizes probably lined up for a more
efficient match to the task.

All three installations were as similar as I could make them.  All
used ext3 filesystems.  All had the identical base Debian Etch system
installation fresh and then install bonnie++ and then run the test.
All three used mem=512M to avoid bonnie running for hours.

I can't explain the results but that is the data I collected.  I
remember going back and running some cases again just to make sure of
the results since I was suspicious of the results.  There is probably
something in there that invalidates the benchmarks.  I definitely
encourage others to do their own benchmarks.  Can I put any more
disclaimers in here?  In the end I stopped worrying about it.  I had
to stop playing and get to work.  I decided to go with aes256 full
disk encryption.  I hardly notice it.  Disks are relatively slow
already but memory buffer cache makes up a lot for it and the same is
true for encrypted filesystems.  At least that used to be true before
the recent fsync() fiasco.

That was in 2007.  It is now 2011 and I am still running that same
system that I eventually installed.  It has been upgraded through two
Debian releases with a third very soon now and one laptop hardware
change to a T43p when the display died on my old T42.  I just moved
the disk, rebuilt the initrd for the new hardware, and logged in.

Bob



More information about the NCLUG mailing list