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] [day] [month] [year] [list]

Date:   Mon, 29 Jan 2018 08:27:48 +0100
From:   Mike Galbraith <efault@....de>
To:     Lai Jiangshan <jiangshanlai@...il.com>
Cc:     Wen Yang <wen.yang99@....com.cn>, Tejun Heo <tj@...nel.org>,
        zhong.weidong@....com.cn, Jiang Biao <jiang.biao2@....com.cn>,
        Tan Hu <tan.hu@....com.cn>,
        kernel test robot <xiaolong.ye@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set
 workqueue's scheduler

On Mon, 2018-01-29 at 14:33 +0800, Lai Jiangshan wrote:
> On Mon, Jan 29, 2018 at 12:41 PM, Mike Galbraith <efault@....de> 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 hands.  The kernel wanting to run a workqueue does not justify
> > perturbing the user's critical task.
> 
> The kworkers doesn't belong to any user, it is really needlessly invasive
> if we give the ability to any user to control the priority of the kworkers.

In a scenario where box is being saturated by RT, every last bit of the
box is likely in the (hopefully capable) hands of a solo box pilot.
 With a prio-boosting scheme, which user gets to choose the boost
priority for the global resource?

> If the user's critical task calls flush_work(). the critical task should
> boost one responsible kworker. (the kwoker scheduled for
> the work item, or the first idle kworker or the manager kworker,
> the kwoker for the later two cases is changing, need to migrate
> the boosting to a new kworker when needed)
> 
> The boosted work items need to be moved to a prio list in the pool
> too for the boosted kworker to pick it up.

Userspace knows which of its actions are wired up to what kernel
mechanism?  New workers are never spawned, stepping on any
prioritization userspace does?

I don't want to argue about it really, I'm just expressing my opinion
on the matter.  I have a mechanism in place to let users safely do
whatever they like, have for years, and it's not going anywhere.  That
mechanism was born from the needs of users, not mine.  First came a
user with a long stable product that suddenly ceased to function due to
workqueues learning to spawn new threads, then came a few cases where
users were absolutely convinced that they really really did need to be
able to safely saturate.  I could have said tough titty, adapt your
product to use a dedicated kthread to the one, and no you just think
you need to do that to the others, but I'm not (quite) that arrogant,
gave them the control they wanted instead.

	-Mike