From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEED7C282C3 for ; Tue, 22 Jan 2019 12:45:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B932B20855 for ; Tue, 22 Jan 2019 12:45:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728474AbfAVMpw (ORCPT ); Tue, 22 Jan 2019 07:45:52 -0500 Received: from foss.arm.com ([217.140.101.70]:52624 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728215AbfAVMpw (ORCPT ); Tue, 22 Jan 2019 07:45:52 -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 7D424EBD; Tue, 22 Jan 2019 04:45:51 -0800 (PST) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8726C3F614; Tue, 22 Jan 2019 04:45:48 -0800 (PST) Date: Tue, 22 Jan 2019 12:45:46 +0000 From: Patrick Bellasi To: Quentin Perret 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: <20190122124546.njrpmykzbjpztd6u@e110439-lin> References: <20190115101513.2822-1-patrick.bellasi@arm.com> <20190115101513.2822-12-patrick.bellasi@arm.com> <20190122121321.r6mv23ao57uut3t7@queper01-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190122121321.r6mv23ao57uut3t7@queper01-lin> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22-Jan 12:13, Quentin Perret wrote: > On Tuesday 15 Jan 2019 at 10:15:08 (+0000), Patrick Bellasi wrote: > > The Energy Aware Scheduler (AES) estimates the energy impact of waking [...] > > + 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 ? By default configuration, RT tasks still go to max when uclamp is enabled, since they get a util_min=1024. If we want to save power on RT tasks, we can set a smaller util_min... but not necessarily 0. A util_min=0 for RT tasks means to use just cpu_util_rt() for that class. > 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. Default behavior for RT should not be affected. While a capping is possible for those tasks... where do you see issues ? Here we are just figuring out what's the capacity the task will run at, if we will have clamped RT tasks will not be the max but: is that a problem ? > > + 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 -- #include Patrick Bellasi