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 5C6913793AA for ; Fri, 27 Mar 2026 17:10:43 +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=1774631447; cv=none; b=VtuaDocMmrgmbIV9HUifsG1v+jZUat2I8UIGA5UHdHpBDXlc4UwibEpV0Yk4uikcTOEwQ7GJrC0rQNSJI1TlYXq8Y1Tq4Ahw6VyruKjudLu7p6HybN5t5hxZlVDYsu7Aeil3YjUVw2oH1a0CthBG9zX2WAoxieWZYtT6fllT4Fw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774631447; c=relaxed/simple; bh=k8X2cEbRlGJlR9P1Kj2M6QI5kYg1ISsYZ66hnBcoCZY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=W2eZJSPCI70rv6OLxt9Y9Qws+YOMpEcI71WRxtncy+QxLD+caWxqzXPa6x/poMVn7KFwVERQEdhW5a4WZdMCxcJ2+UjtNwFgDkxo9pV8AnUJX1PjpzMm63vjjUpVEscVA3oqzmbibpLIYlppkZWqzzifION0p4Lf5gjDo6fhDJQ= 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=PW1s5bOs; 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="PW1s5bOs" 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 606F635FD; Fri, 27 Mar 2026 10:10:36 -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 81D833F99C; Fri, 27 Mar 2026 10:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774631442; bh=k8X2cEbRlGJlR9P1Kj2M6QI5kYg1ISsYZ66hnBcoCZY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=PW1s5bOsvZB8Pq2+WdIl4eTqDPs8di84L05F1aXPdVAvCuO/uzYKjAvxFYue6ZhiF QUeN8kv8uqsz30MAD5JMrnca20IF59pQaUm+/zIYS9OLisYjVP4Zg+kihcwSgjDxrN 1LYuFVH2VbgQzYBXUQBHdKeuagiQQgaZDne4Bbl0= Message-ID: Date: Fri, 27 Mar 2026 18:10:38 +0100 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] sched/fair: Use sched_energy_enabled() To: Vincent Guittot , K Prateek Nayak Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org References: <20260327132013.2800517-1-vincent.guittot@linaro.org> <458b21f7-6640-450c-889c-d05c6b0d801e@amd.com> From: Dietmar Eggemann Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.03.26 17:32, Vincent Guittot wrote: > On Fri, 27 Mar 2026 at 17:18, K Prateek Nayak wrote: >> >> Hello Vincent, >> >> On 3/27/2026 6:50 PM, Vincent Guittot wrote: >>> Use helper sched_energy_enabled() everywhere we want to test if EAS is >>> enabled instead of mixing sched_energy_enabled() and direct call to >>> static_branch_unlikely(). >>> >>> No functional change >>> >>> Signed-off-by: Vincent Guittot >> >> Feel free to include: >> >> Reviewed-by: K Prateek Nayak >> Tested-by: K Prateek Nayak >> >>> --- >>> kernel/sched/topology.c | 9 ++++----- >>> 1 file changed, 4 insertions(+), 5 deletions(-) >>> >>> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c >>> index 43150591914b..5847b83d9d55 100644 >>> --- a/kernel/sched/topology.c >>> +++ b/kernel/sched/topology.c >>> @@ -273,7 +273,7 @@ void rebuild_sched_domains_energy(void) >>> static int sched_energy_aware_handler(const struct ctl_table *table, int write, >>> void *buffer, size_t *lenp, loff_t *ppos) >>> { >>> - int ret, state; >>> + int ret; >>> >>> if (write && !capable(CAP_SYS_ADMIN)) >>> return -EPERM; >>> @@ -289,8 +289,7 @@ static int sched_energy_aware_handler(const struct ctl_table *table, int write, >>> >>> ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); >>> if (!ret && write) { >>> - state = static_branch_unlikely(&sched_energy_present); >>> - if (state != sysctl_sched_energy_aware) >>> + if (sysctl_sched_energy_aware != sched_energy_enabled()) >> >> Quick tangential question: >> >> Since "sysctl_sched_energy_aware" is initialized to "1", if >> build_perf_domains() returns false at boot, sysctl_sched_energy_aware >> and sched_energy_enabled() will go out of sync and reading >> "/proc/sys/kernel/sched_energy_aware" will still show "1" despite EAS >> being disabled. >> >> Is that okay? > > Isn't the call to sched_is_eas_possible() there to prevent this case ? Yes, I think so: 300 static const struct ctl_table sched_energy_aware_sysctls[] = { ... 302 .procname = "sched_energy_aware", ... 306 .proc_handler = sched_energy_aware_handler, 273 sched_energy_aware_handler() ... 281 if (!sched_is_eas_possible(cpu_active_mask)) { <-- !!! 282 if (write) { 283 return -EOPNOTSUPP; 284 } else { 285 *lenp = 0; 286 return 0; 287 } ... # cat /proc/sys/kernel/sched_energy_aware 1 # ./set_cpufreq_ondemand.sh cat /proc/sys/kernel/sched_energy_aware [ 391.591167] rd 0-5: Checking EAS: cpufreq is not ready Reviewed-by: Dietmar Eggemann [...]