Received: by 10.192.165.156 with SMTP id m28csp1096575imm; Wed, 18 Apr 2018 04:09:52 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/x9fRfBY4ud8hUXV02YdlLYF7fODyCsLTa/JrQf6NnzzPQmM27nzKb0Bjig5xb3JbXODsI X-Received: by 10.167.130.151 with SMTP id s23mr1603341pfm.106.1524049792256; Wed, 18 Apr 2018 04:09:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524049792; cv=none; d=google.com; s=arc-20160816; b=iPb6IjAa8GhQb400YrrNkQgXn0Df3dNar0XVW1XuOhYXnr+AfqFCZuWxu/zJIOxF1d XEwxUvr+r+I5VLV6/QjMh+Izh7tTJy3Wo2dJSKhLrMkD0igsCfYX38xp48cih9GEsCP8 m9u4tZOqr85bgTRy44tRrg02JpKp+UwGLDVvpgcHYNrnV9fYBuCzXcqkjtuc9P7TMHsl 9F0cgXkFB7KasIb3cSnY1/1F4+JDz8WbapYxNO0JrsN3vt0IgJHGjdFZgRrl4wZmP6Ar kPnBMj/Bl54Mjtyl8IjwDF3LA4zOhfrf1UE4rPxyF6CtFy+ptNL/e2Y7X7+dgXEagIEn LRlQ== 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=E8ofbZp4c1VabaBB8iO2YxSfn+gF3sSjxt2zhRYA1Lo=; b=GtGL6mDr3rD/Vd017ou8a11d2Zf5t+5J8K+3qJGQeMdk3+hUOzM+SwUOWUIH7Z4Y1n sux+XG8fDoBB7TNCUdEH2RJtl5xTjVTfh/b8b9pxg9ZTtHIyXZhWr2pQ2yP3sCtWMHB2 zIHrAJM2dYtUfmQj+WicMbKJaURNLKSH7U9LZYWX0MYMwNwISHYC4mJJRXJZ3aojj0eq GfTLip4g4JE0shRL8ZsVDlAtd/+q577G4F4Sg6WOPZGKHv+ay2M8n7JPxYir7HQGjUG8 yRyWVVDu2t52h4dbGbcnyg52jMEN2NRWos4XZyQB3oSQ7wdUokA18FEHjGUVrKsD3Lzz hd9w== 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 3-v6si1023495plv.323.2018.04.18.04.09.36; Wed, 18 Apr 2018 04:09:52 -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 S1753442AbeDRLGp (ORCPT + 99 others); Wed, 18 Apr 2018 07:06:45 -0400 Received: from foss.arm.com ([217.140.101.70]:53460 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752911AbeDRLGo (ORCPT ); Wed, 18 Apr 2018 07:06:44 -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 562681529; Wed, 18 Apr 2018 04:06:44 -0700 (PDT) Received: from e108498-lin.cambridge.arm.com (e108498-lin.cambridge.arm.com [10.1.210.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3F4BC3F487; Wed, 18 Apr 2018 04:06:41 -0700 (PDT) Date: Wed, 18 Apr 2018 12:06:35 +0100 From: Quentin Perret To: Leo Yan Cc: Dietmar Eggemann , linux-kernel@vger.kernel.org, Peter Zijlstra , Thara Gopinath , linux-pm@vger.kernel.org, Morten Rasmussen , Chris Redpath , Patrick Bellasi , Valentin Schneider , "Rafael J . Wysocki" , Greg Kroah-Hartman , Vincent Guittot , Viresh Kumar , Todd Kjos , Joel Fernandes , Juri Lelli , Steve Muckle , Eduardo Valentin Subject: Re: [RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function Message-ID: <20180418110635.GA6783@e108498-lin.cambridge.arm.com> References: <20180406153607.17815-1-dietmar.eggemann@arm.com> <20180406153607.17815-5-dietmar.eggemann@arm.com> <20180417152213.GC18509@leoy-ThinkPad-X240s> <20180418081339.GB3943@e108498-lin.cambridge.arm.com> <20180418091928.GA15682@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180418091928.GA15682@leoy-ThinkPad-X240s> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 18 Apr 2018 at 17:19:28 (+0800), Leo Yan wrote: > > > BTW, CPU utilization is decayed value and task_util() is not decayed > > > value, so 'util - task_util(p)' calculates a smaller value than the > > > prev CPU pure utilization, right? > > > > task_util() is the raw PELT signal, without UTIL_EST, so I think it's > > fine to do `util - task_util()`. > > > > > > > > Another question is can we reuse the function cpu_util_wake() and > > > just compenstate task util for dst cpu? > > > > Well it's not that simple. cpu_util_wake() will give you the max between > > the util_avg and the util_est value, so which task_util() should you add > > to it ? The util_avg or the uti_est value ? > > If feature 'UTIL_EST' is enabled, then add task's util_est; otherwise > add task util_avg value. I don't think this is correct. If UTIL_EST is enabled, cpu_util_wake() will return the max between the util_avg and the util_est. When you call it, you don't know what you get. Adding the _task_util_est() to cpu_util_wake() is wrong if cpu_util_avg > cpu_util_est for example. > > I think cpu_util_wake() has similiar logic with here, it merely returns > CPU level util; but here needs to accumulate CPU level util + task level > util. So seems to me, the logic is: > > cpu_util_wake() + task_util_wake() I'm not sure to get that one ... What is task_util_wake() ? Thanks, Quentin