Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v3 4/5] sched/pelt: Add a new runnable average signal
To:     Vincent Guittot <vincent.guittot@linaro.org>
Cc:     Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Phil Auld <pauld@redhat.com>, Parth Shah <parth@linux.ibm.com>,
        Hillf Danton <hdanton@sina.com>
References: <20200214152729.6059-5-vincent.guittot@linaro.org>
 <20200219125513.8953-1-vincent.guittot@linaro.org>
 <9fe822fc-c311-2b97-ae14-b9269dd99f1e@arm.com>
 <CAKfTPtD4kz07hikCuU2_cm67ntruopN9CdJEP+fg5L4_N=qEgg@mail.gmail.com>
 <d9f78b94-2455-e000-82bd-c00cfb9bbc8e@arm.com>
 <CAKfTPtAQ_09wVM7zjrHDB+gJXpb5OH6CBvfKC7OB_Bo0Hd41vA@mail.gmail.com>
From:   Valentin Schneider <valentin.schneider@arm.com>
Message-ID: <e4def999-b784-6b26-3748-a2ad57f79c6d@arm.com>
Date:   Mon, 24 Feb 2020 15:57:36 +0000
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAKfTPtAQ_09wVM7zjrHDB+gJXpb5OH6CBvfKC7OB_Bo0Hd41vA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

I somehow lost track of that email, sorry for the delayed response.

On 2/21/20 8:56 AM, Vincent Guittot wrote:
> On Thu, 20 Feb 2020 at 17:11, Valentin Schneider
> <valentin.schneider@arm.com> wrote:
>>
>> On 20/02/2020 14:36, Vincent Guittot wrote:
>>> I agree that setting by default to SCHED_CAPACITY_SCALE is too much
>>> for little core.
>>> The problem for little core can be fixed by using the cpu capacity instead
>>>
>>
>> So that's indeed better for big.LITTLE & co. Any reason however for not
>> aligning with the initialization of util_avg ?
> 
> The runnable_avg is the unweighted version of the load_avg so they
> should both be sync at init and SCHED_CAPACITY_SCALE is in fact the
> right value. Using cpu_scale is the same for smp and big core so we
> can use it instead.
> 
> Then, the initial value of util_avg has never reflected some kind of
> realistic value for the utilization of a new task, especially if those
> tasks will become big ones. Runnable_avg now balances this effect to
> say that we don't know what will be the behavior of the new task,
> which might end up using all spare capacity although current
> utilization is low and CPU is not "fully used".

I'd argue that the init values we pick for either runnable_avg or util_avg
are both equally bogus.

> In fact, this is
> exactly the purpose of runnable: highlight that there is maybe no
> spare capacity even if CPU's utilization is low because of external
> event like task migration or having new tasks with most probably wrong
> utilization.
> 
> That being said, there is a bigger problem with the current version of
> this patch, which is that I forgot to use runnable in
> update_sg_wakeup_stats(). I have a patch that fixes this problem.
> 
> Also, I have tested both proposals with hackbench on my octo cores and
> using cpu_scale gives slightly better results than util_avg, which
> probably reflects the case I mentioned above.
> 
> grp     cpu_scale            util_avg               improvement
> 1       1,191(+/-0.77 %)     1,204(+/-1.16 %)       -1.07 %
> 4       1,147(+/-1.14 %)     1,195(+/-0.52 %)       -4.21 %
> 8       1,112(+/-1,52 %)     1,124(+/-1,45 %)       -1.12 %
> 16      1,163(+/-1.72 %)     1,169(+/-1.58 %)       -0,45 %
> 

Interesting, thanks for providing the numbers. I'd be curious to figure out
where the difference really stems from, but in the meantime consider me
convinced ;)