Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754301AbcKHTuV (ORCPT ); Tue, 8 Nov 2016 14:50:21 -0500 Received: from merlin.infradead.org ([205.233.59.134]:46740 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753973AbcKHTuS (ORCPT ); Tue, 8 Nov 2016 14:50:18 -0500 Date: Tue, 8 Nov 2016 20:50:15 +0100 From: Peter Zijlstra To: Daniel Bristot de Oliveira Cc: Steven Rostedt , Ingo Molnar , Christoph Lameter , linux-rt-users , LKML , Tommaso Cucinotta Subject: Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Message-ID: <20161108195015.GP3117@twins.programming.kicks-ass.net> References: <20161108115958.GO3142@twins.programming.kicks-ass.net> <20161108090740.4226ffc9@gandalf.local.home> <20161108165133.GI3117@twins.programming.kicks-ass.net> <20161108121710.3e7eb664@gandalf.local.home> <20161108180548.GN3117@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) X-MIME-Error: demime acl condition: uuencoded line length is not a multiple of 4 characters Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1229 Lines: 30 On Tue, Nov 08, 2016 at 08:29:49PM +0100, Daniel Bristot de Oliveira wrote: > > > On 11/08/2016 07:05 PM, Peter Zijlstra wrote: > >> > > >> > I know what we want to do, but there's some momentous problems that > >> > need to be solved first. > > Like what? > > The problem is that using RT_RUNTIME_SHARE a CPU will almost always > borrow enough runtime to make a CPU intensive rt task to run forever... > well not forever, but until the system crash because a kworker starved > in this CPU. Kworkers are sched fair by design and users do not always > have a way to avoid them in an isolated CPU, for example. > > The user then can disable RT_RUNTIME_SHARE, but then the user will have > the CPU going idle for (period - runtime) at each period... throwing CPU > time in the trash. So why is this a problem? You really should not be running that much FIFO tasks to begin with. So I'm willing to take out (or at least default disable RT_RUNTIME_SHARE). But other than this, this never really worked to begin with. So it cannot be a regression. And we've lived this long with the 'problem'. And that means this is a 'feature' and that means I say no. We really should be doing the right thing here, not make a bigger mess.