linux-kernel - Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1517056644.6501.27.camel@gmx.de>
Date:   Sat, 27 Jan 2018 13:37:24 +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 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