> I think earlier you (or someone else in this thread?) were mentioning that the slowdown is a > function of array speed (higher is worse) and processing power (slower is worse). It certainly seems that way, though I don't have enough data-points to be able to call it a function. Actually I've tried to find a way to put a hard cap on a block device's speed in order to test this but there doesn't seem to be an easy solution, or one that would allow throtteling I/Os to/from the dm-crypt mapper device itself. > With AES hardware acceleration coming to mainstream x86 with the next generation of Intel > boards, would you expect the issue to be allayed? Maybe. I've no idea how much benefit AES-NI has in practice. Hopefully that isn't going to be an excuse for not impementing multi-threaded dm-crypt. Is there a technical/algorithmical reason why multiple cores couldn't work on a single dm-crypt device? Even if larger requests can't be (easily) split, maybe unrelated ones could? Hell, even a fixed mapping of addresses to cores would probably help. > I expect the last scenario scales up to a core/disk ratio of one? The test box has only two cores, so that's 2:1. Won't be able to test 1:1 for a while since my only quadcore is in use right now. > Is the advantage still there, when you've only got one core available? Is there a way to tell the kernel to disable one core at boot? The BIOS doesn't have an option for it on this board. Thanks, C. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
