> > > 2) scale up the number of workqueue threads used for a single dm-crypt > > device so that a device can realize per-cpu concurrency (to address > > Andi's scalability concerns: https://patchwork.kernel.org/patch/244031/) They are already addressed in my patchkit and the patches seem to be used by more and more users. It's just you guys who are behind. > > > > [the desired locality is currently missing due to dm-crypt's current > > use of WQ_UNBOUND; so it is clear the way the workqueues are created > > will be important] > > I don't know enough about dm-crypt workload to tell whether per-cpu > affinity would be better or not, but it's really a simple matter of CPU affinity and an own thread makes sense for the crypto helper because it uses up a lot of CPU time. For the IO helper you probably still want CPU affinity, but it can be concurrency managed. -andi -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
