fix parallelism for rpc tasks

"Linux Kernel Mailing List" <[email protected]>
Newsgroups gmane.linux.kernel.commits.head
Message-ID <[email protected]>
Web:        https://git.kernel.org/torvalds/c/f515f86b34b2e7d4b24cc9b7375c9e749895088e
Commit:     f515f86b34b2e7d4b24cc9b7375c9e749895088e
Parent:     90ea9f1b60c679049619a79d9fc1557bc41c4973
Refname:    refs/heads/master
Author:     Olga Kornievskaia <[email protected]>
AuthorDate: Thu Jun 29 09:25:36 2017 -0400
Committer:  Trond Myklebust <[email protected]>
CommitDate: Thu Feb 8 16:24:35 2018 -0500

    fix parallelism for rpc tasks
    
    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 <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
---
 net/sunrpc/sched.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 25e6051e97f2..d9db2eab3a8d 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -1104,7 +1104,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;
--
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.