Messages in this thread Patch in this message | | | Subject | Re: [RFC PATCH 0/4] softirq: Per vector threading v3 | From | Mike Galbraith <> | Date | Tue, 23 Jan 2018 19:01:20 +0100 |
| |
On Tue, 2018-01-23 at 09:42 -0800, Linus Torvalds wrote: > On Tue, Jan 23, 2018 at 8:57 AM, Paolo Abeni <pabeni@redhat.com> wrote: > > > >> Or is it that the workqueue execution is simply not yielding for some > >> reason? > > > > It's like that. > > > > I spent little time on it, so I haven't many data point. I'll try to > > investigate the scenario later this week. > > Hmm. workqueues seem to use cond_resched_rcu_qs(), which does a > cond_resched() (and a RCU quiescent note). > > But I wonder if the test triggers the "lets run lots of workqueue > threads", and then the single-threaded user space just gets blown out > of the water by many kernel threads. Each thread gets its own "fair" > amount of CPU, but..
If folks aren't careful with workqueues, they can be a generic starvation problem. Like the below in the here and now.
fs/nfs: Add a resched point to nfs_commit_release_pages()
During heavy NFS write, kworkers can do very large amounts of work without scheduling (82ms traced). Add a resched point.
Signed-off-by: Mike Galbraith <efault@gmx.de> Suggested-by: Trond Myklebust <trondmy@primarydata.com> --- fs/nfs/write.c | 1 + 1 file changed, 1 insertion(+)
--- a/fs/nfs/write.c +++ b/fs/nfs/write.c @@ -1837,6 +1837,7 @@ static void nfs_commit_release_pages(str set_bit(NFS_CONTEXT_RESEND_WRITES, &req->wb_context->flags); next: nfs_unlock_and_release_request(req); + cond_resched(); } nfss = NFS_SERVER(data->inode); if (atomic_long_read(&nfss->writeback) < NFS_CONGESTION_OFF_THRESH)
| |