On Fri, May 6, 2022 at 5:44 PM Tom Talpey <tom@xxxxxxxxxx> wrote: > > 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? > Hi Tom, I'm actually profiling cifs.ko performance for a customer who's running a set of benchmark tests which tries to capture their actual workloads. One such workload is the one with a single application process that is pumping random async writes to a handful of files on the system. So the app expects that the request is queued asap before being unblocked, so that it can move on to the next request. Seems like a fair ask. On profiling cifs.ko, I found that all the other CPUs are fairly idle, when one cpu is kept busy in queuing up requests. And because it does encryption and tcp send as a part of queuing up requests, I feel that it is not as fast as it should be. I feel that if this task is spread out across the other CPUs (by the way of delegation), the I/Os can unblock much more quickly, thereby keeping many more requests in-flight quickly, Note that this is only theoretical so far. I will try it out and see if that is actually what happens, but I wanted to collect opinions on whether there are any down-sides to this approach. > > 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. -- Regards, Shyam
