Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1156454imm; Tue, 5 Jun 2018 09:55:17 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKXJyIS4XHuk6p1lNndC+IuDSjs+zjVvttEcE7is5wn35gz+Tfqw0QbRuQRvji3K9ey/0Zt X-Received: by 2002:aa7:860e:: with SMTP id p14-v6mr13715530pfn.155.1528217717302; Tue, 05 Jun 2018 09:55:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528217717; cv=none; d=google.com; s=arc-20160816; b=dcvabVfIDXKOusJk8An0gaXqFlXk6K4X4PS/NsKh8nHvdZfQp3btEuteyR02+1Ars5 P857rx2IBFEfhDuvUUbBtvPZN+cPZ0yHcUo4m2E2p2agTsW2cyV/A558m7SCJ/glqlQf 1voKoywzuInl0+BGAIKTR5uTAFBxX5ch9nN9jDjNvmiiybsn9L7zXa5lvnn2AJg260Oc +HPxQMQx1hY9/68A5jS+yxnvzzrss9j/FZ3qcuOovWHaj0mibcRFrG9zS+gdSRU1hYW8 LQvE+aPrXRjtXK0u3gjJ/9y4pkv40gsQVAB9CLXK6Xp2XphIrB6Yw0BcH/k6r9AOrsli AePw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=xT84l7DIrzwICaGx4qpKwDiL7XorY/rZ7hEclX9mT6g=; b=0c4otH4kWv5ftitxKM+LTgblh6bEHz6db6EBqhgrqtSRlpo8ZCsrcZdZTHeXNGming DhReK9mpGwoaIkZcsH6A1YEXitI4LyeOXrSRERi034w0gGN8kgNLMwc+4dljSBJGKTgj 8P76RTV0T1zwSZDBv1q2v1jaXUftogzfOseTw7iDsz3wDB+HgPSDZzdR/YaxGTDPmR3T fpOKHk4JUZ86dbVydGyk3A1bdEx78XlqE6peb4+kqG4Z86un2rcdUqrED6A9CTd1XKDW kJI1ldF2DElbt8sdpHtHMyBtKyvhxyAUYnp1+0kE20AX39hUvDTDf6KzTNGu6O2zJuxd lZVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g9-v6si48043507plt.232.2018.06.05.09.55.02; Tue, 05 Jun 2018 09:55:17 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751853AbeFEQyi (ORCPT + 99 others); Tue, 5 Jun 2018 12:54:38 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:58584 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbeFEQyg (ORCPT ); Tue, 5 Jun 2018 12:54:36 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 761391435; Tue, 5 Jun 2018 09:54:36 -0700 (PDT) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 425703F59D; Tue, 5 Jun 2018 09:54:34 -0700 (PDT) Date: Tue, 5 Jun 2018 17:54:31 +0100 From: Patrick Bellasi To: Juri Lelli Cc: Vincent Guittot , linux-kernel , "open list:THERMAL" , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Dietmar Eggemann , Morten Rasmussen , Joel Fernandes , Steve Muckle , Todd Kjos Subject: Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking Message-ID: <20180605165431.GF32302@e110439-lin> References: <20180604160600.22052-1-patrick.bellasi@arm.com> <20180604160600.22052-3-patrick.bellasi@arm.com> <20180605151129.GC32302@e110439-lin> <20180605153105.GM16081@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180605153105.GM16081@localhost.localdomain> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- #include Patrick Bellasi