From: Mike Galbraith <efault@gmx.de>
To: Wen Yang <wen.yang99@zte.com.cn>, tj@kernel.org
Cc: zhong.weidong@zte.com.cn, Jiang Biao <jiang.biao2@zte.com.cn>,
Tan Hu <tan.hu@zte.com.cn>,
Lai Jiangshan <jiangshanlai@gmail.com>,
kernel test robot <xiaolong.ye@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler
Date: Sat, 27 Jan 2018 10:31:44 +0100 [thread overview]
Message-ID: <1517045504.15811.18.camel@gmx.de> (raw)
In-Reply-To: <1517030127-21391-5-git-send-email-wen.yang99@zte.com.cn>
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
next prev parent reply other threads:[~2018-01-27 9:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-27 5:15 [RFC PATCH V5 1/5] workqueue: rename system workqueues Wen Yang
2018-01-27 5:15 ` [RFC PATCH V5 2/5] workqueue: expose attrs for " Wen Yang
2018-01-27 5:15 ` [RFC PATCH V5 3/5] workqueue: rename unbound_attrs to attrs Wen Yang
2018-01-27 5:15 ` [RFC PATCH V5 4/5] workqueue: convert ->nice to ->sched_attr Wen Yang
2018-01-27 5:15 ` [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler Wen Yang
2018-01-27 9:31 ` Mike Galbraith [this message]
2018-01-27 12:37 ` Mike Galbraith
2018-01-29 4:15 ` Lai Jiangshan
2018-01-29 4:41 ` Mike Galbraith
2018-01-29 6:33 ` Lai Jiangshan
2018-01-29 7:27 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1517045504.15811.18.camel@gmx.de \
--to=efault@gmx.de \
--cc=jiang.biao2@zte.com.cn \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tan.hu@zte.com.cn \
--cc=tj@kernel.org \
--cc=wen.yang99@zte.com.cn \
--cc=xiaolong.ye@intel.com \
--cc=zhong.weidong@zte.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox