Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7325743imu; Tue, 22 Jan 2019 04:15:34 -0800 (PST) X-Google-Smtp-Source: ALg8bN7suwu+LfHy9jq9fpYoFr0DvLcD2A9aWHIbi6L6J5F1PRfB0RqIF6bBecHcOpCvWLz/nPUr X-Received: by 2002:a65:4904:: with SMTP id p4mr32070899pgs.384.1548159334311; Tue, 22 Jan 2019 04:15:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548159334; cv=none; d=google.com; s=arc-20160816; b=XfgDX86yk0MtzMw5EJOUvk1wNH7gI7+3yCwC8p6lLG42cgkva1P+Zx8qFcnSlOv/lB m13M2MMrWvg5aw2SEYpy9m2ksclFzp42LId3RXrNonR4fcXTyBgr20ZqbUxgo5UeKBC4 Yya3x0Cfqluk2cHcUjtJaq2BcO+qQ8wLDGlJZARzC1t1jeaFVAAG4BDsTa6jNjtdN6pq Cfr6oidGhjEIh7F/XnoOT59hPU9B3swXq1KPK+VUk7nPubaE47Qym0RGaH0OWfQJliVL mB6JmMGMwuxxQyw0Dxn2fRDxCjic2hEFD4j6OaLzyM2gKJIVjawaNremc7aiRqBDambi ugtQ== 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; bh=NeujtOVhgGd2hM54CQ1QA/umDJCvzVmSVVfamWTObd4=; b=h20lu4yQyTdS3M1qXd2OwjcZ1gOE3bU2I31K6GUU1o1iWRj5fz3gv/i3GGeWx1iCw8 gozPsa9+EuXxOMMlT0ZXNqnzz0Nux12LbultnKKYcEGyq1j+2FoDiuYr5dkjVqpF2ym1 wncVm70vAW33V/0/W3keweIJi2tOjTD58FThqUFvtG29ZFBmGm1H48TVvu30H7XYsqah bYzc6AWwsrLm2cfwmbRwxViOZuG9ZcYmVl/5xW2HUV9DokXAaVtXm+jtpBy+r9h9VEqs ypRuiCY0H8TCbzm6xB/o6ziIAJjyL8W5g8QnKeuAlO3rTp0BoNUdMrjMZG0FRWeAoyI2 kqow== 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 p17si14866295pfk.275.2019.01.22.04.15.08; Tue, 22 Jan 2019 04:15:34 -0800 (PST) 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 S1728361AbfAVMN1 (ORCPT + 99 others); Tue, 22 Jan 2019 07:13:27 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52238 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728239AbfAVMN1 (ORCPT ); Tue, 22 Jan 2019 07:13:27 -0500 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 8827CA78; Tue, 22 Jan 2019 04:13:26 -0800 (PST) Received: from queper01-lin (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 934103F614; Tue, 22 Jan 2019 04:13:23 -0800 (PST) Date: Tue, 22 Jan 2019 12:13:22 +0000 From: Quentin Perret To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v6 11/16] sched/fair: Add uclamp support to energy_compute() Message-ID: <20190122121321.r6mv23ao57uut3t7@queper01-lin> References: <20190115101513.2822-1-patrick.bellasi@arm.com> <20190115101513.2822-12-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190115101513.2822-12-patrick.bellasi@arm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 15 Jan 2019 at 10:15:08 (+0000), Patrick Bellasi wrote: > The Energy Aware Scheduler (AES) estimates the energy impact of waking s/AES/EAS :-) [...] > + for_each_cpu_and(cpu, pd_mask, cpu_online_mask) { > + cfs_util = cpu_util_next(cpu, p, dst_cpu); > + > + /* > + * Busy time computation: utilization clamping is not > + * required since the ratio (sum_util / cpu_capacity) > + * is already enough to scale the EM reported power > + * consumption at the (eventually clamped) cpu_capacity. > + */ Right. > + sum_util += schedutil_cpu_util(cpu, cfs_util, cpu_cap, > + ENERGY_UTIL, NULL); > + > + /* > + * Performance domain frequency: utilization clamping > + * must be considered since it affects the selection > + * of the performance domain frequency. > + */ So that actually affects the way we deal with RT I think. I assume the idea is to say if you don't want to reflect the RT-go-to-max-freq thing in EAS (which is what we do now) you should set the min cap for RT to 0. Is that correct ? I'm fine with this conceptually but maybe the specific case of RT should be mentioned somewhere in the commit message or so ? I think it's important to say that clearly since this patch changes the default behaviour. > + cpu_util = schedutil_cpu_util(cpu, cfs_util, cpu_cap, > + FREQUENCY_UTIL, > + cpu == dst_cpu ? p : NULL); > + max_util = max(max_util, cpu_util); > } > > energy += em_pd_energy(pd->em_pd, max_util, sum_util); Thanks, Quentin