On Mon, 2018-01-29 at 14:33 +0800, Lai Jiangshan wrote:
> On Mon, Jan 29, 2018 at 12:41 PM, Mike Galbraith wrote:
> > On Mon, 2018-01-29 at 12:15 +0800, Lai Jiangshan wrote:
> >> I think adding priority boost to workqueue(flush_work()) is the best
> >> way to fix the problem.
> >
> > I disagree, p
On Mon, Jan 29, 2018 at 12:41 PM, Mike Galbraith wrote:
> On Mon, 2018-01-29 at 12:15 +0800, Lai Jiangshan wrote:
>> I think adding priority boost to workqueue(flush_work()) is the best
>> way to fix the problem.
>
> I disagree, priority boosting is needlessly invasive, takes control out
> of user
On Mon, 2018-01-29 at 12:15 +0800, Lai Jiangshan wrote:
> I think adding priority boost to workqueue(flush_work()) is the best
> way to fix the problem.
I disagree, priority boosting is needlessly invasive, takes control out
of user hands. The kernel wanting to run a workqueue does not justify
pe
I think adding priority boost to workqueue(flush_work()) is the best
way to fix the problem.
On Sat, Jan 27, 2018 at 1:15 PM, 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 inve
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
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
6 matches
Mail list logo
