From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C7B5B3CF205 for ; Tue, 9 Jun 2026 07:04:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780988671; cv=none; b=s7I2pkkiDQuJiISgEfPzQv5cC7QAlUhNF/ZpX2Mq95V1xCCxvAeUHQcl46j28Ca4tYmCPBWyF48aTFX4XIybw1Bn7L1SR7ImjJaSXPTXuCLfUSqnPlUQYQMOxa6YMmk8W3iNAxIBxpWqfzfuNI2iS7f+egeKyrJc7AIIJcbMo4E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780988671; c=relaxed/simple; bh=+WrTbJ+p+QBqw+rvcFLro2lMxg7F7a89e6oj/zJ4RaY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YNg3/EIhY8jafeVpN/dnfTE/X3A2okt31dYJjfhe+rZ59ZFb8XNZUGkwvaiG6CxxDCP3neoI64vRdDLjgdw/I3twKwtnnlXMtKJTAvc3WhPYVJS3ceRpt0hMDOGolp22FOacSP+qdcwS0rQ9VD9zvae7xA0wq6XDl5x5Q6k3MM4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=axAT5inX; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="axAT5inX" 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 2C3532681; Tue, 9 Jun 2026 00:04:23 -0700 (PDT) Received: from [192.168.178.6] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 278353FE53; Tue, 9 Jun 2026 00:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1780988667; bh=+WrTbJ+p+QBqw+rvcFLro2lMxg7F7a89e6oj/zJ4RaY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=axAT5inXOoRfMQiOkdSdJ6XzEl/5BSReRSKa5sab8K6zOYq26JQ382RIwTUkW5Lw7 Gh7YSPITPBYn5zaHzXkH+9F0CBkezn+nMzjtxe0Psljem6QNligxHUP1+qA9opUuks AIMF8ep/0PXJWqBNaAwMqBAEjc9FwhdZdgfToUw4= Message-ID: Date: Tue, 9 Jun 2026 09:04:20 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] sched/fair: Fix cpu_util runnable_avg arithmetic To: Hongyan Xia , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak Cc: Jiazi Li , "linux-kernel@vger.kernel.org" References: <20260605094318.37931-1-hongyan.xia@transsion.com> <5aac4ca7-9b13-4e44-908c-5c273d3d8c68@transsion.com> Content-Language: en-GB From: Dietmar Eggemann In-Reply-To: <5aac4ca7-9b13-4e44-908c-5c273d3d8c68@transsion.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.06.26 15:15, Hongyan Xia wrote: > On 6/5/2026 6:35 PM, Dietmar Eggemann wrote: >> On 05.06.26 11:43, Hongyan Xia wrote: >>> From: Hongyan Xia >>> >>> If we take runnable_avg in max(runnable_avg, util_avg) in cpu_util(), we >>> should then add or subtract task runnable_avg, but the arithmetic below >>> is still with task util_avg. This mixes runnable_avg with util_avg which >>> is incorrect. >>> >>> Fix by always doing arithmetic with runnable_avg and only take >>> max(runnable_avg, util_avg) at the last step. >>> >>> Fixes: 7d0583cf9ec7 ("sched/fair, cpufreq: Introduce 'runnable boosting'") >>> Signed-off-by: Hongyan Xia >> >> Does this fix the issue in EAS energy calculation you mentioned >> initially? We now add/subtract task rbl_avg from CPU rbl_avg but can we >> now use this value correctly in util_avg based EAS? > > It does improve things a bit. It used to occasionally pile up tasks on > the same CPU, which happens less after this patch. At least it now gets > the maths right so this fix should probably be in regardless. Just to map this into the code: --- EAS ---: compute_energy(..., p, dst_cpu) max_util = eenv_pd_max_util(..., p, dst_cpu) for_each_cpu(cpu, pd_cpus) util = cpu_util(cpu, p, dst_cpu, 1) ^ boost energy = em_pd_get_efficient_state(..., max_util) for (i = min_ps; i <= max_ps; i++) if (ps->performance >= max_util) return i --- schedutil ---: sugov_get_util(cpu) util =+ cpu_util_cfs_boost(cpu) util = cpu_util(cpu, NULL, -1, 1) --> p == NULL, dst_cpu == -1 ^ boost This can help to calculate a more correct max_util value on the EAS-side, but won't change schedutil? I agree that it's more correct to add/subract task runnable in case of migration but using runnable instead of util vs capacity is still not 'correct'? >> How do you want to solve the power consumption regression in you >> low-power use cases? Since you mentioned per-CPU tasks in those >> contention scenarios (per-CPU worker vs producer *), do you plan to only >> use boost in cpu_util() in case the affinity of p (worker) is not >> constrained? Not sure whether the consumer (CPU affinity not >> constrained) also has rbl_avg > util_avg? > > This patch only gets the maths right but the energy regression is still > big because frequency hasn't changed. The producer-consumer is only the > worst offender, not the only one. Trouble is that runnable_avg is just a > big number to deal with in general, and you could easily double or > triple your frequency if you have many small threads around (which is > the case in our mobile cases). > > We haven't found a good solution to solve it completely. I keep > wondering if there could be a better metric than raw runnable_avg. One > that is not so big in magnitude and does a much better job to tell the > true contention where boosting frequency helps. > >> * >> https://lore.kernel.org/r/4adbab4d-f9e4-4354-aa1e-48f11b1fd208@transsion.com >> >> >> [...]