Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp5341323pxv; Wed, 7 Jul 2021 01:12:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwih+EXWtYn6OlQq/JcXIJ+SENpd9UfAK6Wu8trpMHe7zuhafp3QeyxZr2sX1yld7SfzFdh X-Received: by 2002:a17:907:da9:: with SMTP id go41mr22015711ejc.403.1625645550429; Wed, 07 Jul 2021 01:12:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625645550; cv=none; d=google.com; s=arc-20160816; b=vOIjebaX+PHQ9agHnn/oYOmt8b9KMGu5iO16UNrNtLSwBQIUxe0hRQ7/CJtdknx77T hmHSG8PXTHJqGIopHArIoZxqGqk7IbEXUm4+TPQYKz5qraToAMRarSibaPxoO9EVqzKb yKbz/hzMkS/TDwaUnORvsInVz22bW6HIKLEMSYM/xxrbzuh+H50o5BYHVr6O2qkJtumt TRh2aVo3jWO6es3p6C4mu64qnyWYtB2pNJiSavqceUNapD3rONshDxWE7WaEi+jjB/5q qTqfx/TcR9FmpWN3zaserkrC/66497vPq2nzOdZck5o7ljhs217JZfRJQqufiVpHBanJ KGnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=AKWEnJvoRRrLd9IXUqkpJriOCpWYsRQGtQrNxVV/0iM=; b=jlftVM9On3fKRgQL3wtDfPFupMbKIWRrZTfhHsZiOEOtQi8ln8uZgEU268FfHKSUAj hzEQSCprWtMjs4nuyrNOGnTHGBz4PSLtUxsVwItsBL5LfG81K7CvvK0+Wx7fgCkBcNhU 5LItERJIVkOwCF7UYZ8bL8625+T/7POGYlCYr7dc23iJVuZZ/ofX4Ob3jHjEyzOUlnje K2czGvte+i+o/JLplFrV5JARcEilCSJAn9YzlFYoOBe2QW39I+OWXFcmX+p4IQmMdDpv DqOIeTvIMfTxvOI24crwLkYgzNlzUIUsPnUyMoCKaqQvDbFldsAlt/K/MNv3rh/JqPTr crvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h9si17812126edb.389.2021.07.07.01.12.07; Wed, 07 Jul 2021 01:12:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230438AbhGGILz (ORCPT + 99 others); Wed, 7 Jul 2021 04:11:55 -0400 Received: from foss.arm.com ([217.140.110.172]:59318 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230398AbhGGILy (ORCPT ); Wed, 7 Jul 2021 04:11:54 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 99274ED1; Wed, 7 Jul 2021 01:09:14 -0700 (PDT) Received: from [10.57.1.129] (unknown [10.57.1.129]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B20833F694; Wed, 7 Jul 2021 01:09:11 -0700 (PDT) Subject: Re: [PATCH 2/3] PM: EM: Make em_cpu_energy() able to return bigger values To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Chris.Redpath@arm.com, dietmar.eggemann@arm.com, morten.rasmussen@arm.com, qperret@google.com, linux-pm@vger.kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org, vincent.guittot@linaro.org, mingo@redhat.com, juri.lelli@redhat.com, rostedt@goodmis.org, segall@google.com, mgorman@suse.de, bristot@redhat.com, CCj.Yeh@mediatek.com References: <20210625152603.25960-1-lukasz.luba@arm.com> <20210625152603.25960-3-lukasz.luba@arm.com> From: Lukasz Luba Message-ID: Date: Wed, 7 Jul 2021 09:09:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/7/21 8:07 AM, Peter Zijlstra wrote: > On Fri, Jun 25, 2021 at 04:26:02PM +0100, Lukasz Luba wrote: >> The Energy Model (EM) em_cpu_energy() is responsible for providing good >> estimation regarding CPUs energy. It contains proper data structures which >> are then used during calculation. The values stored in there are in >> milli-Watts precision (or in abstract scale) smaller that 0xffff, which use >> sufficient unsigned long even on 32-bit machines. There are scenarios where >> we would like to provide calculated estimations in a better precision and >> the values might be 1000 times bigger. This patch makes possible to use >> quite big values for also 32-bit machines. >> >> Signed-off-by: Lukasz Luba >> --- >> include/linux/energy_model.h | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h >> index 3f221dbf5f95..2016f5a706e0 100644 >> --- a/include/linux/energy_model.h >> +++ b/include/linux/energy_model.h >> @@ -101,7 +101,7 @@ void em_dev_unregister_perf_domain(struct device *dev); >> * Return: the sum of the energy consumed by the CPUs of the domain assuming >> * a capacity state satisfying the max utilization of the domain. >> */ >> -static inline unsigned long em_cpu_energy(struct em_perf_domain *pd, >> +static inline u64 em_cpu_energy(struct em_perf_domain *pd, >> unsigned long max_util, unsigned long sum_util, >> unsigned long allowed_cpu_cap) >> { >> @@ -180,7 +180,7 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd, >> * pd_nrg = ------------------------ (4) >> * scale_cpu >> */ >> - return ps->cost * sum_util / scale_cpu; >> + return div_u64((u64)ps->cost * sum_util, scale_cpu); > > So these patches are all rather straight forward, however.. the above is > pretty horrific on a 32bit box, and we do quite a few of them per > wakeup. Is this really worth the performance penalty on 32bit CPUs? True, for 2 cluster SoC we might do this 5 times (or less, depends on system state). We don't have new 32bit big.LITTLE platforms, the newest is ~7years old and is actually the only one using EAS. It's not put into new devices AFAIK. > > Do you really still care about 32bit CPUs, or is this mostly an artifact > of wanting to unconditionally increase the precision? > We discussed this internally and weighted the 32bit old big.little. There is a solution, but needs more work and a lot of changes in the whole kernel due to modified EM (affects IPA, DTPM, registration, ...). I have been working on a next step for code that you've pointed: get rid of this runtime division. It would be possible to pre-calculate the: 'ps->cost / scale_cpu' at the moment when EM is registered and store it in the ps->cost. So we would have just: return ps->cost * sum_util The only issue is a late boot of biggest cores, which would destroy the old scale_cpu values for other PDs. I need to probably add RCU locking into the EM and update the other PDs' EMs when the last biggest CPU boots after a few second and registers its EM. For now we would live with this simple code which improves all recent 64bit platforms and is easy to take it into Android common kernel. The next step would be more scattered across other subsystems, so harder to backport to Android 5.4 and others.