From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933058AbcA1Nlk (ORCPT ); Thu, 28 Jan 2016 08:41:40 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:35279 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751633AbcA1Nlh (ORCPT ); Thu, 28 Jan 2016 08:41:37 -0500 Date: Thu, 28 Jan 2016 14:41:29 +0100 From: luca abeni To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Juri Lelli Subject: Re: [RFC 4/8] Improve the tracking of active utilisation Message-ID: <20160128144129.789ca176@utopia> In-Reply-To: <20160128122100.GD6357@twins.programming.kicks-ass.net> References: <1452785094-3086-1-git-send-email-luca.abeni@unitn.it> <1452785094-3086-5-git-send-email-luca.abeni@unitn.it> <20160114194323.GC6357@twins.programming.kicks-ass.net> <569E29FD.9040909@unitn.it> <20160119134739.GY6357@twins.programming.kicks-ass.net> <20160127143651.4de18ad9@luca-1225C> <20160127143946.GR6357@twins.programming.kicks-ass.net> <20160128121441.0ebde65d@utopia> <20160128122100.GD6357@twins.programming.kicks-ass.net> Organization: university of trento X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, On Thu, 28 Jan 2016 13:21:00 +0100 Peter Zijlstra wrote: > On Thu, Jan 28, 2016 at 12:14:41PM +0100, luca abeni wrote: > > I am looking at the PI stuff right now... And I am not sure if > > SCHED_DEADLINE does the right thing for PI :) > > Strictly speaking it does not, dl-pi is a giant hack. > > Some day we should fix this :-) I am trying to have a better look at the code, and I think that implementing bandwidth inheritance (BWI) could be easy (implementing M-BWI, that can be analyzed on multi-processor systems, is more complex because it requires busy waiting or similar). > But as you might be aware, SMP capable PI protocols for this are > somewhat tricky. Right :) > > Anyway, I think the total SCHED_DEADLINE utilization (rd->dl_bw) is > > currently not changed when a SCHED_OTHER task is boosted to > > SCHED_DEADLINE due to PI... Right? > > From memory that is accurate, but not right as per the above. Ideally > we would indeed charge the boosted task against the booster's > bandwidth. Yes, this would be the BWI approach > This has the 'fun' consequence that while you deplete the bandwidth of > the booster the PI order can change and we should pick another booster > etc. > > > Is this the desired behaviour? > > Nope, but fixing this is likely to be non-trivial. Ok... So, if this is acceptable for this patchset I'll try to keep the current PI behaviour, and I'll try to have a look at a better PI protocol after the runtime reclaiming stuff is done (that is, I make it acceptable for mainline, or we decide that a different approach is needed). Luca