, Mikulas Patocka wrote:
Questions: If you are optimizing it, 1) why don't you optimize it in such a way that if one CPU submits requests, the crypto work is spread among all the CPUs? Currently it spreads the work only if different CPUs submit it.
This case is only useful with very slow CPUs and is handled by pcrypt in theory (but I haven't tested it)
2) why not optimize software async crypto daemon (crypt/cryptd.c) instead of dm-crypt, so that all kernel subsystems can actually take advantage of those multi-CPU optimizations, not just dm-crypt?
Normally most subsystems are multi-CPU already, unless they limit themselves artitifically like dm-crypt. For dm-crypt would be wasteful to funnel everything through two single CPU threads just to spread it out again. That is why I also used per CPU IO threads too. -Andi -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
