Re: ?dm-crypt latency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gunter Ohrner wrote:
> However, I'm also using reiserfs, I will try if ext3 shows better
> responsiveness and report back if it does.

Ok, I did a few additional tests.

Summary: The problem is not reiser related, but seems to have something to
do with the filesystem layer(?).

The follwing numbers should be taken with a grain of salt as I didn't
measure this on a completely idle system. My normal desktop environment was
running, although I did not do anyting disk or CPU intensive in parallel
besides switching through open windows switching to check for system
responsiveness.

I did something as simple as

   dd if=/dev/zero of=test.null bs=4M count=1024 ; rm test.null

to an unencrypted partition, to two encrypted partitions, one reiser, one
ext3, and to the raw encrypted block device.

During writes, kcryptd ate 100% CPU, as it's to be expected, my CPU(s) being
the limiting factor in encrypted write performance.

I got the following numbers:

* Target: unencrypted disk partition
  4294967296 Bytes (4,3 GB) kopiert, 91,8375 s, 46,8 MB/s
  No noticeable latency problems.

* Target: encrypted reiser partion with AES 128
  4294967296 Bytes (4,3 GB) kopiert, 104,348 s, 41,2 MB/s
  Mouse movement stayed smooth, but that was about it. Everything IO
  related, including a playing music stream, blocked for up to several
  seconds (!) every few seconds.

* Target: encrypted ext3 partition with AES 256
  4294967296 Bytes (4,3 GB) kopiert, 137,841 s, 31,2 MB/s
  Just the same behaviour as with the reiser AES 128 partition.

* Target: raw AES 256 encrypted device (previously hosting the test ext3 fs)
  4294967296 Bytes (4,3 GB) kopiert, 128,149 s, 33,5 MB/s
  Here we virtually get the same / similar thorughput as with the filesystem
  in between, but without the latency problems: While kcryptd was also at
  100%, music was payling back continuously and other IO also didn't block,
  windows switching an mouse hover actions causing the targeted application
  to initiate some disk IO (eg. icon highlighting) stayed smooth.

Changing the kcryptd's and kcryptd_io's nice value from -5 to 10 using
renice did not show any significant change or even improvement, I still had
these high latencies when writing the nulls.

Ok, any idea how to debug this further? It's a really annoying problem, it's
even more annoying considering how simple the encrypted partitions setup
and use are. :-(

Greetings,

  Gunter


---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux