From mboxrd@z Thu Jan 1 00:00:00 1970 From: Quentin Perret Subject: Re: [RFC PATCH 1/7] PM: Introduce em_pd_get_higher_freq() Date: Thu, 16 May 2019 14:01:50 +0100 Message-ID: <20190516130148.uhq55ptut47usnae@queper01-lin> References: <20190508174301.4828-1-douglas.raillard@arm.com> <20190508174301.4828-2-douglas.raillard@arm.com> <20190516124200.opxczohjelhvrzmo@e110439-lin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190516124200.opxczohjelhvrzmo@e110439-lin> Sender: linux-kernel-owner@vger.kernel.org To: Patrick Bellasi Cc: douglas.raillard@arm.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, dietmar.eggemann@arm.com List-Id: linux-pm@vger.kernel.org On Thursday 16 May 2019 at 13:42:00 (+0100), Patrick Bellasi wrote: > > +static inline unsigned long em_pd_get_higher_freq(struct em_perf_domain *pd, > > + unsigned long min_freq, unsigned long cost_margin) > > +{ > > + unsigned long max_cost = 0; > > + struct em_cap_state *cs; > > + int i; > > + > > + if (!pd) > > + return min_freq; > > + > > + /* Compute the maximum allowed cost */ > > + for (i = 0; i < pd->nr_cap_states; i++) { > > + cs = &pd->table[i]; > > + if (cs->frequency >= min_freq) { > > + max_cost = cs->cost + (cs->cost * cost_margin) / 1024; > ^^^^ > ... end here we should probably better use SCHED_CAPACITY_SCALE > instead of hard-coding in values, isn't it? I'm not sure to agree. This isn't part of the scheduler per se, and the cost thing isn't in units of capacity, but in units of power, so I don't think SCHED_CAPACITY_SCALE is correct here. But I agree these hard coded values (that one, and the 512 in one of the following patches) could use some motivation :-) Thanks, Quentin 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_HELO_NONE,SPF_PASS,USER_AGENT_NEOMUTT autolearn=unavailable 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 8B20EC04AAF for ; Thu, 16 May 2019 13:02:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E2DC20848 for ; Thu, 16 May 2019 13:02:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727103AbfEPNCF (ORCPT ); Thu, 16 May 2019 09:02:05 -0400 Received: from foss.arm.com ([217.140.101.70]:45000 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726528AbfEPNCE (ORCPT ); Thu, 16 May 2019 09:02:04 -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 72BB51715; Thu, 16 May 2019 06:02:04 -0700 (PDT) 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 1BD1B3F703; Thu, 16 May 2019 06:02:02 -0700 (PDT) Date: Thu, 16 May 2019 14:01:50 +0100 From: Quentin Perret To: Patrick Bellasi Cc: douglas.raillard@arm.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, dietmar.eggemann@arm.com Subject: Re: [RFC PATCH 1/7] PM: Introduce em_pd_get_higher_freq() Message-ID: <20190516130148.uhq55ptut47usnae@queper01-lin> References: <20190508174301.4828-1-douglas.raillard@arm.com> <20190508174301.4828-2-douglas.raillard@arm.com> <20190516124200.opxczohjelhvrzmo@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <20190516124200.opxczohjelhvrzmo@e110439-lin> User-Agent: NeoMutt/20171215 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Message-ID: <20190516130150.8eyDYvkk0JNMvrAn_UEA1qfAUMp3hOmqd5yAqXIkFE8@z> On Thursday 16 May 2019 at 13:42:00 (+0100), Patrick Bellasi wrote: > > +static inline unsigned long em_pd_get_higher_freq(struct em_perf_domain *pd, > > + unsigned long min_freq, unsigned long cost_margin) > > +{ > > + unsigned long max_cost = 0; > > + struct em_cap_state *cs; > > + int i; > > + > > + if (!pd) > > + return min_freq; > > + > > + /* Compute the maximum allowed cost */ > > + for (i = 0; i < pd->nr_cap_states; i++) { > > + cs = &pd->table[i]; > > + if (cs->frequency >= min_freq) { > > + max_cost = cs->cost + (cs->cost * cost_margin) / 1024; > ^^^^ > ... end here we should probably better use SCHED_CAPACITY_SCALE > instead of hard-coding in values, isn't it? I'm not sure to agree. This isn't part of the scheduler per se, and the cost thing isn't in units of capacity, but in units of power, so I don't think SCHED_CAPACITY_SCALE is correct here. But I agree these hard coded values (that one, and the 512 in one of the following patches) could use some motivation :-) Thanks, Quentin