From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S966444AbcA1MVK (ORCPT <rfc822;w@1wt.eu>);
	Thu, 28 Jan 2016 07:21:10 -0500
Received: from casper.infradead.org ([85.118.1.10]:35569 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933742AbcA1MVE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Jan 2016 07:21:04 -0500
Date: Thu, 28 Jan 2016 13:21:00 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: luca abeni <luca.abeni@unitn.it>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@arm.com>
Subject: Re: [RFC 4/8] Improve the tracking of active utilisation
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160128121441.0ebde65d@utopia>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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 :-)

But as you might be aware, SMP capable PI protocols for this are
somewhat tricky.

> 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.

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.