On Thu, 2017-06-29 at 09:25 -0400, Olga Kornievskaia wrote: > Hi folks, > > On a multi-core machine, is it expected that we can have parallel > RPCs > handled by each of the per-core workqueue? > > In testing a read workload, observing via "top" command that a single > "kworker" thread is running servicing the requests (no parallelism). > It's more prominent while doing these operations over krb5p mount. > > What has been suggested by Bruce is to try this and in my testing I > see then the read workload spread among all the kworker threads. > > Signed-off-by: Olga Kornievskaia <kolga@xxxxxxxxxx> > > diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c > index 0cc8383..f80e688 100644 > --- a/net/sunrpc/sched.c > +++ b/net/sunrpc/sched.c > @@ -1095,7 +1095,7 @@ static int rpciod_start(void) > * Create the rpciod thread and wait for it to start. > */ > dprintk("RPC: creating workqueue rpciod\n"); > - wq = alloc_workqueue("rpciod", WQ_MEM_RECLAIM, 0); > + wq = alloc_workqueue("rpciod", WQ_MEM_RECLAIM | WQ_UNBOUND, 0); > if (!wq) > goto out_failed; > rpciod_workqueue = wq; > WQ_UNBOUND turns off concurrency management on the thread pool (See Documentation/core-api/workqueue.rst. It also means we contend for work item queuing/dequeuing locks, since the threads which run the work items are not bound to a CPU. IOW: This is not a slam-dunk obvious gain. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx ��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥