On Fri, Aug 07 2020 at 4:11pm -0400, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Aug 7, 2020 at 9:03 AM Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > > - DM crypt improvement to optionally avoid async processing via > > workqueues for reads and/or writes -- via "no_read_workqueue" and > > "no_write_workqueue" features. This more direct IO processing > > improves latency and throughput with faster storage. Avoiding > > workqueue IO submission for writes (DM_CRYPT_NO_WRITE_WORKQUEUE) is > > a requirement for adding zoned block device support to DM crypt. > > Is there a reason the async workqueue isn't removed entirely if it's not a win? > > Or at least made to not be the default. I haven't assessed it yet. There are things like rbtree sorting that is also hooked off async, but that is more meaningful for rotational storage. > Now it seems to be just optionally disabled, which seems the wrong way > around to me. > > I do not believe async crypto has ever worked or been worth it. > Off-loaded crypto in the IO path, yes. Async using a workqueue? Naah. > > Or do I misunderstand? No, you've got it. My thinking was to introduce the ability to avoid the workqueue code via opt-in and then we can evaluate the difference it has on different classes of storage. More conservative approach that also allows me to not know the end from the beginning... this was work driven by others so on this point I rolled with what was proposed since I personally don't have the answer (yet) on whether workqueue is actually helpful. Best to _really_ know that before removing it. I'll make a point to try to get more eyes on this to see if it makes sense to just eliminate the workqueue code entirely (or invert the default). Will keep you updated. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
