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 038A43BFE56 for ; Thu, 19 Mar 2026 10:18:10 +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=1773915494; cv=none; b=jcyU+8ww7Uuz+2NQb9aqSdamxKwOzhweJUUaxRFAjfrQdCRlEq1miI1n8lxq9pt1Oo6aBM9TaDyjk+k/H+HsCKD05v94CDseVBPdjfatK814pqmlurM2BTNZdIgbhVDSMGT8VGsOuxM1KBQd7NVmr3nS06SR3wax1UveDSRwGK8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773915494; c=relaxed/simple; bh=jyagbGgCNDN90ZPRwm4Dd9gCnKXx8RxOFx0p2d8NFTE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rMFPh0ttmlG1pda8V0tLzlccaHjqp4PTLLr/QhdDKjTuuElKOoTYC0r/txOb6aWIfM/9cxF4qeHML0PukoLl8qR5ngcNCXxdoxuEFI6+/N57wdk3QJd87qcGyJXG8DD440xwnIQt0esT7Glp7zsHLSUwNOVwFogGNOuVFHtz8bY= 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; 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 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 159911A25; Thu, 19 Mar 2026 03:18:04 -0700 (PDT) Received: from [10.57.20.4] (unknown [10.57.20.4]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6508A3F7BD; Thu, 19 Mar 2026 03:18:06 -0700 (PDT) Message-ID: <5a5d565b-33ac-4d5c-b0dd-1353324a6117@arm.com> Date: Thu, 19 Mar 2026 10:18:21 +0000 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: [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util() To: Xuewen Yan , Qais Yousef Cc: Vincent Guittot , Peter Zijlstra , Xuewen Yan , mingo@redhat.com, juri.lelli@redhat.com, tj@kernel.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, rui.zhang@intel.com, di.shen@unisoc.com, ke.wang@unisoc.com, Christian Loehle References: <20260318121755.16354-1-xuewen.yan@unisoc.com> <20260318124718.GC3738786@noisy.programming.kicks-ass.net> <20260318134406.6k23fct6dvpsqagm@airbuntu> Content-Language: en-US From: Lukasz Luba In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Qais and Xuewen, On 3/19/26 02:13, Xuewen Yan wrote: > On Wed, Mar 18, 2026 at 9:44 PM Qais Yousef wrote: >> >> On 03/18/26 13:55, Vincent Guittot wrote: >>> On Wed, 18 Mar 2026 at 13:47, Peter Zijlstra wrote: >>>> >>>> On Wed, Mar 18, 2026 at 08:17:55PM +0800, Xuewen Yan wrote: >>>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>>>> index bf948db905ed..20adb6fede2a 100644 >>>>> --- a/kernel/sched/fair.c >>>>> +++ b/kernel/sched/fair.c >>>>> @@ -8198,7 +8198,12 @@ unsigned long effective_cpu_util(int cpu, unsigned long util_cfs, >>>>> >>>>> unsigned long sched_cpu_util(int cpu) >>>>> { >>>>> - return effective_cpu_util(cpu, cpu_util_cfs(cpu), NULL, NULL); >>>>> + unsigned long util = scx_cpuperf_target(cpu); >>>>> + >>>>> + if (!scx_switched_all()) >>>>> + util += cpu_util_cfs(cpu); >>>>> + >>>>> + return effective_cpu_util(cpu, util, NULL, NULL); >>>>> } >>>> >>>> This puts the common case of no ext muck into the slow path of that >>>> static_branch. >>> >>> +1 >>> I was about to same >>> >>>> >>>> This wants to be something like: >>>> >>>> unsigned long sched_cpu_util(int cpu) >>>> { >>>> unsigned long util = cpu_util_cfs(cpu); >>>> >>>> if (scx_enabled()) { >>>> unsigned long scx_util = scx_cpuperf_target(cpu); >>> >>> also scx_cpuperf_target() does not reflect the utilization of the CPU >>> but the targeted perfromance level >> >> Beside that, this sort of plug-and-play is a big concern. You picked up sched >> ext and changed the behavior, then you'd need to get your thermal management to >> work with that. Not retrospectively sprinkle these hacks around to force things >> to work again. > > In fact, I had considered this issue even before sending this patch. > Our initial fix was to modify the thermal subsystem specifically, > in cpufreq_cooling.c, when SCX is enabled, we stopped calling > sched_cpu_util() and instead used idle-time-based calculation to > obtain CPU util. > > However, we later realized that sched_cpu_util() is used not only in > cpufreq_cooling.c but also in dtpm_cpu.c. > Since I’m not familiar with dtpm_cpu.c, I was hesitant to modify it. > This led us to propose the current patch. > Although scx_cpuperf_target may not accurately reflect the true CPU > utilization, as Christian pointed out, it’s still better than having > nothing at all. > > That’s exactly why I marked this patch as RFC, I wasn’t sure whether > the proper fix should be in cpufreq_cooling.c or in sched_cpu_util(). > It now seems clear that modifying only sched_cpu_util() is > insufficient. Ideally, we should also update cpufreq_cooling.c, since > we cannot guarantee that all SCX BPF programs will provide an accurate > cpuperf_target. > I’ll submit a follow-up patch to modify cpufreq_cooling.c shortly. > If you refer to the utilization driven power estimation - I tend to agree. You might remember, we had a few corner-cases due to that design and I tried to address it differently [1][2]. Xuewen please send your proposal for the cpufreq_cooling.c and I will have a look there. If there still be a need to fix it more deeply then I can help with some deeper thermal changes. Estimating the real CPU's power based on available information in the kernel is really hard. Although, let's try to fix what you observe in your devices. Regards, Lukasz [1] https://lore.kernel.org/linux-pm/20210622075925.16189-1-lukasz.luba@arm.com/ [2] https://lore.kernel.org/linux-pm/20220406220809.22555-1-lukasz.luba@arm.com/