On 5/6/2022 7:28 AM, Shyam Prasad N wrote:
Hi, This is a question for anyone who understands the async I/O codepath better than I do: Today, we have the esize mount option, which delegates the task of decryption to worker threads. But the task of encryption still happens in the context of the i/o thread. If the i/o process does synchronous read/write, it isn't such a big deal. But if it's an async i/o, there is a potentially significant perf gain that we can make if we can offload the heavy lifting to worker threads, and let the main thread move on to the next request.
How do you measure "perf gain"? Won't the extra context switching increase the client CPU load? Generally speaking, an application doing async i/o is already carefully managing parallelism. Are you certain that adding more will always be a win? Will the application performance overall actually improve?
What do you all feel about moving the server->ops->async_writev (and async_readv) to a worker thread? Do you see any potential challenges if we go that route?
Need more data. Tom.
