Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1517056644.6501.27.camel@gmx.de>
Subject: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set
 workqueue's scheduler
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
Date:   Sat, 27 Jan 2018 13:37:24 +0100
In-Reply-To: <1517045504.15811.18.camel@gmx.de>
References: <1517030127-21391-1-git-send-email-wen.yang99@zte.com.cn>
         <1517030127-21391-5-git-send-email-wen.yang99@zte.com.cn>
         <1517045504.15811.18.camel@gmx.de>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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