On Tue, 1 Jun 2010, Andi Kleen wrote: > , 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) Almost every CPU is "very slow" so that it lags behind disk when encrypting. CPUs with hardware AES may be the exception. > > 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. If one CPU submits I/O for 10MB of data, your patch makes no paralelization at all. Because all those 10MB will be encrypted by the same CPU that submitted it. > -Andi Mikulas -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
