public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 13:37:24 +0100	[thread overview]
Message-ID: <1517056644.6501.27.camel@gmx.de> (raw)
In-Reply-To: <1517045504.15811.18.camel@gmx.de>

On Sat, 2018-01-27 at 10:31 +0100, Mike Galbraith wrote:
> 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.

P.S. You can also meet inversion expressly due to having excluded
unbound kworkers.  Just yesterday, I was tracing dbench, and both
varieties of kworker were involved in the chain.  An RT task doing
anything at all involving unbound kworkers meets an inversion the
instant an unbound kworker doing work on its behalf has to wait for a
SCHED_OTHER task, if that wait can in any way affect RT progress.

	-Mike

  reply	other threads:[~2018-01-27 12:37 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
2018-01-27 12:37     ` Mike Galbraith [this message]
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=1517056644.6501.27.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