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 S1754219AbdDKIxR (ORCPT <rfc822;w@1wt.eu>);
        Tue, 11 Apr 2017 04:53:17 -0400
Received: from merlin.infradead.org ([205.233.59.134]:43074 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751255AbdDKIxP (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 11 Apr 2017 04:53:15 -0400
Date: Tue, 11 Apr 2017 10:53:05 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
        dietmar.eggemann@arm.com, Morten.Rasmussen@arm.com,
        yuyang.du@intel.com, pjt@google.com, bsegall@google.com
Subject: Re: [PATCH v2] sched/fair: update scale invariance of PELT
Message-ID: <20170411085305.aik6gdy6n3wa22ok@hirez.programming.kicks-ass.net>
References: <1491815909-13345-1-git-send-email-vincent.guittot@linaro.org>
 <20170410173802.orygigjbcpefqtdv@hirez.programming.kicks-ass.net>
 <20170411075221.GA30421@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20170411075221.GA30421@linaro.org>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 11, 2017 at 09:52:21AM +0200, Vincent Guittot wrote:
> Le Monday 10 Apr 2017 à 19:38:02 (+0200), Peter Zijlstra a écrit :
> > 
> > Thanks for the rebase.
> > 
> > On Mon, Apr 10, 2017 at 11:18:29AM +0200, Vincent Guittot wrote:
> > 
> > Ok, so let me try and paraphrase what this patch does.
> > 
> > So consider a task that runs 16 out of our 32ms window:
> > 
> >    running   idle
> >   |---------|---------|
> > 
> > 
> > You're saying that when we scale running with the frequency, suppose we
> > were at 50% freq, we'll end up with:
> > 
> >    run  idle
> >   |----|---------|
> > 
> > 
> > Which is obviously a shorter total then before; so what you do is add
> > back the lost idle time like:
> > 
> >    run  lost idle
> >   |----|----|---------|
> > 
> > 
> > to arrive at the same total time. Which seems to make sense.
> 
> Yes

OK, bear with me.


So we have:


  util_sum' = utilsum * y^p +

                                 p-1
              d1 * y^p + 1024 * \Sum y^n + d3 * y^0
	                         n=1

For the unscaled version, right?

Now for the scaled version, instead of adding a full 'd1,d2,d3' running
segments, we want to add partially running segments, where r=f*d/f_max,
and lost segments l=d-r to fill out the idle time.

But afaict we then end up with (F=f/f_max):


  util_sum' = utilsum * y^p +

                                         p-1
              F * d1 * y^p + F * 1024 * \Sum y^n + F * d3 * y^0
	                                 n=1

And we can collect the common term F:

  util_sum' = utilsum * y^p +

                                      p-1
              F * (d1 * y^p + 1024 * \Sum y^n + d3 * y^0)
	                              n=1


Which is exactly what we already did.

So now I'm confused. Where did I go wrong?


Because by scaling the contribution we get the exact result of doing the
smaller 'running' + 'lost' segments.