On 12-12-16 01:15 PM, Milan Broz wrote: > > No idea why it turned world non-readable, fixed. Thanks. > But I am afraid I did not find any real situation where these patches > really helps If successive block I/Os from a sequential I/O can all get queued up by different CPU (cores) I can't imagine why that wouldn't help. > See also discussion on dm-devel list, I still think generic > kernel workqueues should be used to provide such parallelization and > we should not duplicate code in dm-crypt... Well, definitely, if the parallelization work is duplicating existing kernel functionality, that needs to be factored out. But regardless... > My suggestion is that using AES-NI extension helps much more with > the current upstream code than anything else (for AES, obviously). But of course. I am sure anyone that has a CPU with AES-NI instructions wouldn't care so much (at all even) about multi-core dm-crypt. But unfortunately not everyone has AES-NI capable processors, yet they might have 4 cores (8 if HT enabled) available, with 3 (7, again if HT is enabled) all sitting around doing nothing while one is grunting away with all of the workload. I wish I could just trade in my laptop for one with AES-NI, but other than the lack of AES-NI it's far better than what I would get in return for trading it in. Kind of like trading in one's Ferrari just because it doesn't have a leather steering-wheel for a Fiat that does have a leather steering wheel. :-/ Cheers, b.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
