From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752186AbeFEUqM (ORCPT ); Tue, 5 Jun 2018 16:46:12 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:32885 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751842AbeFEUqJ (ORCPT ); Tue, 5 Jun 2018 16:46:09 -0400 X-Google-Smtp-Source: ADUXVKKWYmKrsAeFe+Uo+EU0T5I1yv4/Neh2mlxHSpPFlh8tNUxWQn3ptHCUCGLkShb1EYECdl4SFg== Date: Tue, 5 Jun 2018 13:46:08 -0700 From: Joel Fernandes To: Patrick Bellasi Cc: Juri Lelli , Vincent Guittot , linux-kernel , "open list:THERMAL" , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Dietmar Eggemann , Morten Rasmussen , connoro@google.com, Joel Fernandes , Steve Muckle , Todd Kjos Subject: Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking Message-ID: <20180605204608.GA3510@joelaf.mtv.corp.google.com> References: <20180604160600.22052-1-patrick.bellasi@arm.com> <20180604160600.22052-3-patrick.bellasi@arm.com> <20180605151129.GC32302@e110439-lin> <20180605153105.GM16081@localhost.localdomain> <20180605165431.GF32302@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180605165431.GF32302@e110439-lin> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 05, 2018 at 05:54:31PM +0100, Patrick Bellasi wrote: > On 05-Jun 17:31, Juri Lelli wrote: > > On 05/06/18 16:11, Patrick Bellasi wrote: > > > > [...] > > > > > If I run an experiment with your example above, while using the > > > performance governor to rule out any possible scale invariance > > > difference, here is what I measure: > > > > > > Task1 (40ms delayed by the following Task2): > > > mean std max > > > running_avg 455.387449 22.940168 492.0 > > > util_avg 433.233288 17.395477 458.0 > > > > > > Task2 (waking up at same time of Task1 and running before): > > > mean std max > > > running_avg 430.281834 22.405175 455.0 > > > util_avg 421.745331 22.098873 456.0 > > > > > > and if I compare Task1 above with another experiment where Task1 is > > > running alone: > > > > > > Task1 (running alone): > > > mean std min > > > running_avg 460.257895 22.103704 460.0 > > > util_avg 435.119737 17.647556 461.0 > > > > Wait, why again in this last case running_avg != util_avg? :) > > I _think_ it's mostly due to the rouding errors we have because of the > reasons I've explained in the reply to Joel: > > https://lkml.org/lkml/2018/6/5/559 > 20180605152156.GD32302@e110439-lin > > at the end, while commenting about the division overhead. > > I should try the above examples while tracking the full signal at > ___update_load_avg() time. Is that the only issue? I think if a CFS task is blocked by another CFS task due to preemption, then with your patch we would account the CFS blocked time as well into the blocked task's running utilization, which seems incorrect. Or did I miss something? thanks, - Joel