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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 02242C433ED for ; Wed, 7 Apr 2021 14:11:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B173C611C1 for ; Wed, 7 Apr 2021 14:11:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348130AbhDGOLy (ORCPT ); Wed, 7 Apr 2021 10:11:54 -0400 Received: from foss.arm.com ([217.140.110.172]:57824 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234134AbhDGOLx (ORCPT ); Wed, 7 Apr 2021 10:11:53 -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 5BFAA1FB; Wed, 7 Apr 2021 07:11:43 -0700 (PDT) Received: from [10.57.54.6] (unknown [10.57.54.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 590DC3F792; Wed, 7 Apr 2021 07:11:40 -0700 (PDT) From: Pierre Subject: Re: [PATCH] sched/fair: use signed long when compute energy delta in eas To: Xuewen Yan , Dietmar Eggemann , qperret@google.com Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , linux-kernel , Chunyan Zhang , Ryan Y References: <20210330052154.26861-1-xuewen.yan94@gmail.com> <34ce11ad-9c20-7ba7-90d8-4830725bf38a@arm.com> Message-ID: <1ebddd33-4666-1e6e-7788-a3fe28c9e99c@arm.com> Date: Wed, 7 Apr 2021 15:11:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > I test the patch, but the overflow still exists. > In the "sched/fair: Use pd_cache to speed up find_energy_efficient_cpu()" > I wonder why recompute the cpu util when cpu==dst_cpu in compute_energy(), > when the dst_cpu's util change, it also would cause the overflow. The patches aim to cache the energy values for the CPUs whose utilization is not modified (so we don't have to compute it multiple times). The values cached are the 'base values' of the CPUs, i.e. when the task is not placed on the CPU. When (cpu==dst_cpu) in compute_energy(), it means the energy values need to be updated instead of using the cached ones. You are right, there is still a possibility to have a negative delta with the patches at: https://gitlab.arm.com/linux-arm/linux-power/-/commits/eas/next/integration-20210129 Adding a check before subtracting the values, and bailing out in such case would avoid this, such as at: https://gitlab.arm.com/linux-arm/linux-pg/-/commits/feec_bail_out/ I think a similar modification should be done in your patch. Even though this is a good idea to group the calls to compute_energy() to reduce the chances of having updates of utilization values in between the compute_energy() calls, there is still a chance to have updates. I think it happened when I applied your patch. About changing the delta(s) from 'unsigned long' to 'long', I am not sure of the meaning of having a negative delta. I thing it would be better to check and fail before it happens instead. Regards