-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Curious things to note here about md raid. When using encryption on top of an device mapper device (md device), is inheritly slow and should show no improvement for multiple threads doing encryption. Multiple threads could only help improve speeds on multiple independent devices. The device mapper creates an abstraction that pretends multiple devices are one (for raid at least) so dm-crypt could not take advantage of this due to block encryption. If you encrypt multiple raw devices then make a device mapper on them, you would notice improvements in speed. Unfortunately this doesn't work properly, it is an unstable configuration (not sure why, I think both use the same area of the device to store metadata). Just informing, but multiple thread support would be nice. - -Chris Milan Broz wrote: > Sami Liedes wrote: >> On Mon, Sep 08, 2008 at 10:19:41AM +0200, Mathieu SEGAUD wrote: >>>> I too would really like it if dm-crypt could use multiple cores. >>> well, I don't think it would change anything, disk writes are not >>> cpu-bound but io-bound. It could not increase write speed as what really >>> counts here, is time waiting for io-completion. As it is some 1000 >>> magnitude longer than memory write times, which are some 1000 magnitude >>> longer than cpu register accesses, I do not think it would change >>> anything on throughput, ever. >> That's not even nearly true. >> >> For example, I have a three-disk raid system capable of something like >> 200 MB/sec throughput. Using dm-crypt practically limits it to around >> 80 MB/sec (on a Core 2 Quad) since that's the best one crypto thread >> can do. I can assure you I consistently see kcryptd taking 100% of one >> CPU when viewing the output of top. That's very much CPU bound. > > You are right, especially configuration dm-crypt over MD (raid0,1,5) > and possibly exported as NFS is currently limited by one thread doing > encryption. > > On the other side, current implementation is more effective on encrypted > notebooks for example (one user, second core runs other processes etc.) > > See my response some time ago > http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2681 > > Current status is (after some recent discussion): > - dm-crypt need mechanism to add more than one encryption thread > - # of threads should be configurable (maybe even runtime using dm message) > - implementation must support planned barrier support for device-mapper > > (Also note, if there is any hw doing the encryption, more threads become > ineffective - it is limited by crypto hw capabilities, not by main processors > count.) > > So already on TODO, but not with the highest priority:-) > > Milan > -- > mbroz@xxxxxxxxxx > > > --------------------------------------------------------------------- > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIxsugUqv48yGwoxgRCn7yAJ0dI6RmcpfXzAT02ncb4c8wwFWl9wCg8HQa HLow+r6P3K2Hbq2LKprQHmM= =zddg -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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
