At Sat, 01 Mar 2008 12:00:37 +0100, Milan Broz <mbroz@xxxxxxxxxx> wrote: > > Michael Hampton wrote: > > My first suspicion would be that Linux can't get any other I/O off the > > disk when both kcryptd threads are tied up. It was only when one of the > > two threads appeared in top that my music started playing again. Clearly > > I have enough CPU to handle both reading and writing encrypted data at > > once (it's only a 1.2GHz Intel Core 2 Duo). So perhaps only one thread > > should be handling these sorts of sustained write operations, so that > > the other thread can fetch my music off the disk? > > In kernel 2.6.24 is only one thread per crypt device processing writes. > Any chance to test it with 2.6.24? Why is this necessary at all? dm-crypt folklore tells that writes are faster than reads because there is no queuing necessary. At least this was true up to 2.6.1x. I remember that I have done benchmarks that showed about 25mb/s read speed and (near native) 50mb/s write speed. The difference between these two were attributed to the additional queuing and processing by kcryptd that was necessary for reads. This design seemed to change for 2.6.24. Now writes seem to go also via the kcryptd/workqueue route. In addition, there is kcrypt_io that seems to be handling IO request management in a separate thread (sorry I'm not familiar with the details here). In 2.6.25 async cipher patches were merged. I wonder how they are supposed to be async if they are not handled by another thread. So, from 2.6.1x where we had one thread for reads, we now have 2-3 threads for read and writes. Intuition should tell you that 2.6.24 would be slower than the rest. But the opposite is the case. Benchmarking shows 2.6.24 to be the fastest among all its predecessors. Is this due to some clever queue management in workqueues? Or where does these improvements come from? -- Fruhwirth Clemens - http://clemens.endorphin.org --------------------------------------------------------------------- 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
