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 S1752262AbcIORUc (ORCPT <rfc822;w@1wt.eu>);
        Thu, 15 Sep 2016 13:20:32 -0400
Received: from foss.arm.com ([217.140.101.70]:42524 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750878AbcIORUY (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 15 Sep 2016 13:20:24 -0400
Subject: Re: [PATCH 4/7 v3] sched: propagate load during synchronous
 attach/detach
To: Vincent Guittot <vincent.guittot@linaro.org>
References: <1473666472-13749-1-git-send-email-vincent.guittot@linaro.org>
 <1473666472-13749-5-git-send-email-vincent.guittot@linaro.org>
 <896df1f8-c5ee-ae4c-46f0-4f4e76ad19b1@arm.com>
 <CAKfTPtC0dpLYsfn7Li__nr3MX45DX2fBL=ZTDqSuDCYKe2XS_w@mail.gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Yuyang Du <yuyang.du@intel.com>,
        Morten Rasmussen <Morten.Rasmussen@arm.com>,
        Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
        Paul Turner <pjt@google.com>, Benjamin Segall <bsegall@google.com>
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Message-ID: <161f2b72-7674-6f90-9269-9ef1bba242f0@arm.com>
Date: Thu, 15 Sep 2016 18:20:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAKfTPtC0dpLYsfn7Li__nr3MX45DX2fBL=ZTDqSuDCYKe2XS_w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 15/09/16 15:31, Vincent Guittot wrote:
> On 15 September 2016 at 15:11, Dietmar Eggemann
> <dietmar.eggemann@arm.com> wrote:

[...]

>> Wasn't 'consuming <1' related to 'NICE_0_LOAD' and not
>> scale_load_down(gcfs_rq->tg->shares) before the rewrite of PELT (v4.2,
>> __update_group_entity_contrib())?
> 
> Yes before the rewrite, the condition (tg->runnable_avg < NICE_0_LOAD) was used.
> 
> I have used the following examples to choose the condition:
> 
> A task group with only one always running task TA with a weight equals
> to tg->shares, will have a tg's load (cfs_rq->tg->load_avg) equals to
> TA's weight == scale_load_down(tg->shares): The load of the CPU on
> which the task runs, will be scale_load_down(task's weight) ==
> scale_load_down(tg->shares) and the load of others CPUs will be null.
> In this case, all shares will be given to cfs_rq CFS1 on which TA runs
> and the load of the sched_entity SB that represents CFS1 at parent
> level will be scale_load_down(SB's weight) =
> scale_load_down(tg->shares).
> 
> If the TA is not an always running task, its load will be less than
> its weight and less than scale_load_down(tg->shares) and as a result
> tg->load_avg will be less than scale_load_down(tg->shares).
> Nevertheless, the weight of SB is still scale_load_down(tg->shares)
> and its load should be the same as TA. But the 1st part of the
> calculation gives a load of scale_load_down(gcfs_rq->tg->shares)
> because tg_load == gcfs_rq->tg_load_avg_contrib == load. So if tg_load
> < scale_load_down(gcfs_rq->tg->shares), we have to correct the load
> that we set to SEB

Makes sense to me now. Thanks. Peter already pointed out that this math
can be made easier, so you will probably 'scale gcfs_rq's load into tg's
shares' only if 'tg_load >= shares''

[...]