Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp882153pxf; Wed, 7 Apr 2021 14:04:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3wBzVqZZaYkAI0KsQrx4Jmg14z2dbEf6A9GiR04ILojRkqMwhsoB3yCSqNTSBBnnyZlmb X-Received: by 2002:a92:c7b4:: with SMTP id f20mr4185362ilk.170.1617829440296; Wed, 07 Apr 2021 14:04:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617829440; cv=none; d=google.com; s=arc-20160816; b=GEiuH2nX8G+VugWAOURWcSOHE5r1418LFqLZDg3fAcyDI+IaVLQ1ALEpRcQ5gtLUIG 6sWRQzF6QPEdlDtluQjcYEIf7BIGaYHZ6C+I/Z3jgjSdlhReIopk8fJc9b7j6rNwsXY2 eT4J7I6d5Xq9HNhF5xUInp5TKgpNaNivdj/Sdu7GHZSFp2LGvMVwHfopm6M5IDiJ1APV ao3dcv927Hm0k7qdx9nbSgLQz3yPdDJ8sReoIz51WfDzk4T7yJWoj0U46xy7KnorlcHl w7pVpM6A686t/JPqhUebPOW0rWGiqGDJWnzP9DNQfsIGG+KVa+9jRvGGwCLYzxVreUKP 32hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:subject:from; bh=I4zvA8k7iHJxotRKVqtWigZQQUOmGWfSOBTmiIPq3Yk=; b=C+sd+GKmP6fPOmqZY7BD4uiF5KSwIc8DTSinxclMRTG5sp0T6cTJoX+C4wxAI3o6W7 KGWwqmrPlsUVbB11t6TiQhKTMZSkvClDdnLlVkOiW3gkeW++Tg2T7E7hZSikMIj14q40 aL4Ls1RH/60JfvXBiufyEhuUCb0Cl/Deqz+NdkPHIZiiJ/HEAB2voZ7d7Mrmc6m/90Z/ AWLb2SyDcWiB/hC9qAle7m/lrj1E8jfTxBVQ49HepFCkYFOp5T/MvYJBBR0tKf0f+ARd Kgf9aLXmmvLqZqGGc+81tdzMAgu1XmtsVWBElzO5GvbfBJVdd+jxjC8upF2K7MayuPCi XIag== 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 q17si1902214jar.77.2021.04.07.14.03.48; Wed, 07 Apr 2021 14:04:00 -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 S242929AbhDGOLy (ORCPT + 99 others); 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