hi,
i've also posted this to dm-crypt mailing list, but here is some
additional info.
i've encrypted my hard disks (whole root, and other disks)
with "cryptsetup luksFormat --cipher aes-cbc-essiv:sha256 --key-size
256" and formatted them with ext3 (-j -m0 -O dir_index).
i'm using 2.6.15.1 kernel on an athlon xp 2400+ with 1GB RAM, VIA
KT400A/VT8237 chipset.
/proc/crypto for aes:
name : aes
module : kernel
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
i searched for the aes-i586 optimization (that should be in the
kernel?) but i found no other reference to it than
CONFIG_CRYPTO_AES_586=y. guess i'm using the asm optimized code as
there is no other AES option in the kernel.
if i copy files from one encrypted disk to another my cpu usage goes up
to 100% and stays there for the whole copy process. renicing cp itself
doesn't help.
hdparm settings are the same for all disks except the SATA ones.
multcount = 16 (on)
IO_support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
kjournald and pdflush use all the cpu time, where kjournald is usually
at about 40-70% and pdflush goes up to 50-60%. this is while copying
large files. the cpu usage of kcryptd is negligible.
if i copy many small files, kcryptd will eat much more cpu, about
30-40% and the rest will be pdflush and kjournald.
all disks are mounted with -o defaults,noatime.
doing a 'mke2fs -j -m0 -O dir_index /dev/mapper/name' will also rise the
cpu usage to its maximum where pdflush takes about 60-70%.
(mke2fs 1.38 (30-Jun-2005) Using EXT2FS Library version 1.38)
is anyone else seeing this and is there a solution (besides using a
non-journalling fs) or do i have to live with it that encryption eats
all my cpu?
tx,
JG
Am Mittwoch, 1. Februar 2006 22:07, schrieb JG:
> non-journalling fs) or do i have to live with it that encryption eats
> all my cpu?
Yes of course, the encryption process is slower than the disk access, so
encryption will eat 100% cpu while transfering data from/to an encrypted
disk device.
Especially if you copy from one encrypted device to another, so the data
also has to be decrypted first.
Did you expect anything else?
Greetings,
Gunter
--
*********** Powered by AudioScrobbler -> http://www.last.fm/ ***********
22:40 | Sirenia - On The Wane
22:34 | Sirenia - Sister Nightfall
22:28 | Sirenia - Meridian
22:20 | Tristania - Endogenisis
*** PGP-Verschl?sselung bei eMails erw?nscht :-) *** PGP: 0x1128F25F ***
hi,
> Especially if you copy from one encrypted device to another, so the
> data also has to be decrypted first.
thanks for the answer! i've been using encrypted root disks for quite
some time now and didn't see much performance loss or an increase in cpu
usage. i just wanted to be sure it's the en/decrypting between
different disks and not some kernel problem :)
JG