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