From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751464AbeA2H2L convert rfc822-to-8bit (ORCPT ); Mon, 29 Jan 2018 02:28:11 -0500 Received: from mout.gmx.net ([212.227.15.18]:55938 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbeA2H2K (ORCPT ); Mon, 29 Jan 2018 02:28:10 -0500 Message-ID: <1517210868.7290.96.camel@gmx.de> Subject: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler From: Mike Galbraith To: Lai Jiangshan Cc: Wen Yang , Tejun Heo , zhong.weidong@zte.com.cn, Jiang Biao , Tan Hu , kernel test robot , LKML Date: Mon, 29 Jan 2018 08:27:48 +0100 In-Reply-To: References: <1517030127-21391-1-git-send-email-wen.yang99@zte.com.cn> <1517030127-21391-5-git-send-email-wen.yang99@zte.com.cn> <1517200880.10151.15.camel@gmx.de> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K0:WJ1YD4KwsaGADMoZIXzYogU/mpYOyAUwxnQTsUC80PL37gS3uNe 5PdBloUOkGYhuHND1rxLHQ2yHLfxGaXo1ahYkB3P/v7CZyUJwgkICqMyi4/pl96aLrwWFS5 hYsRrmjMP/JMf5QkLmewkcGR6eFLg18rX9u9mRBjYNWmPjrRg7W0MC+3xs8C3Vm4geNp/kT 2G46vv79YdvbqhETzn9Sg== X-UI-Out-Filterresults: notjunk:1;V01:K0:PuXVMig2Z8Q=:jyGvFqxRV2PV0YZ+NUQwly OWCtE9zco1cwi4vhQPfxJRRPlZmbJwekbEh/uVV3GSsWNjNN4WGOT4WI0ErvTfwsfRqf9byxF pwj2iumwQSsxP263LXDqOW8/2IspuGjeZo///aYqavDg8tLSRMKERIwPK3wAAq6uZYqjmIOaB NdJi3OzrZi3Vf/rFJbCWCGcgnlgEnH9384AbVG0175qeBL3Q4/b8zxM1cVIVxQUGyi0QraBNE frxZdmmng1GvO0EoQ8Oe63d2hDGJ73miTGxX36dCose+/zyFwe641rzWlXQk7Qpjll2ZX47Ch Su9eLM9ePhdV3yBnqf6lEh+6Cwoi6tzM5OLH2TssGjm7YpvwcpPpvJlx5bpPFBanbBCDBdfl2 67O+wrFs4YoIVWYsujGIZcIkz8mbilNHaOGNujvb6yr1a1U/NzIkKeC9VxKTrKgtW5+1R9//s n4/wCmUpF47lZSjiRdl7I0BfbePapCXJjv/IGBQnOoX/cu/TQkQLnB+KTStaCllqKHFb8rTGe GOd8/9GFoYVb+on2BzsYKFouJlCTpgFvPqg6e0PyDxJ6LFDggsGWG10CyrmJG5k6P3bhtHz6J M+z8FEkRBJrRgSs7JQOUmCWwr3GQyC5cHq232E5HdY7dJOvK2ZpcMAiNNmbEAQKPFWzxH2FXl tKxg4dFlDwz4qZrN3gUQ+sQ+Kr/QQqwl9wo9nofnM7oT86bjXCwmrnpOYA2X6EWfKMjBhliVy IDrMZ8/UCMWDxIW9XRpOgOUmV3bhqEq4MXeDOy7k9z5C7Pnu2H61XvuxaDYSpKkZAMqYgxoPh FFDOWmSp0fkuTUQPMZ9JPCyBJkQ4Rf288HVJJznA8bivkPICS4= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, 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