[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1517045504.15811.18.camel@gmx.de>
Date: Sat, 27 Jan 2018 10:31:44 +0100
From: Mike Galbraith <efault@....de>
To: Wen Yang <wen.yang99@....com.cn>, tj@...nel.org
Cc: zhong.weidong@....com.cn, Jiang Biao <jiang.biao2@....com.cn>,
Tan Hu <tan.hu@....com.cn>,
Lai Jiangshan <jiangshanlai@...il.com>,
kernel test robot <xiaolong.ye@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set
workqueue's scheduler
On Sat, 2018-01-27 at 13:15 +0800, Wen Yang wrote:
> When pinning RT threads to specific cores using CPU affinity, the
> kworkers on the same CPU would starve, which may lead to some kind
> of priority inversion. In that case, the RT threads would also
> suffer high performance impact.
...
> This patch introduces a way to set the scheduler(policy and priority)
> of percpu worker_pool, in that way, user could set proper scheduler
> policy and priority of the worker_pool as needed, which could apply
> to all the WORK_CPU_BOUND workers on the same CPU.
What happens when a new kworker needs to be spawned? What guarantees
that kthreadd can run? Not to mention other kthreads that can be
starved, resulting in severe self inflicted injury. An interface to
configure workqueues is very nice, but it's only part of the problem.
-Mike
Powered by blists - more mailing lists