Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Message-ID: <7c6dd2ec-b9a9-b364-5a29-05336127e519@linux.vnet.ibm.com>
Date:   Thu, 14 Sep 2023 23:26:55 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH v3] sched/topology: remove sysctl_sched_energy_aware
 depending on the architecture
To:     Valentin Schneider <vschneid@redhat.com>
Cc:     dietmar.eggemann@arm.com, linux-kernel@vger.kernel.org,
        ionela.voinescu@arm.com, quentin.perret@arm.com,
        srikar@linux.vnet.ibm.com, mgorman@techsingularity.net,
        mingo@kernel.org, pierre.gondois@arm.com, yu.c.chen@intel.com,
        tim.c.chen@linux.intel.com, mingo@redhat.com, peterz@infradead.org,
        vincent.guittot@linaro.org
References: <20230913114807.665094-1-sshegde@linux.vnet.ibm.com>
 <xhsmhil8cvi7s.mognet@vschneid.remote.csb>
Content-Language: en-US
From:   Shrikanth Hegde <sshegde@linux.vnet.ibm.com>
In-Reply-To: <xhsmhil8cvi7s.mognet@vschneid.remote.csb>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 9/14/23 9:51 PM, Valentin Schneider wrote:
> On 13/09/23 17:18, Shrikanth Hegde wrote:
>> sysctl_sched_energy_aware is available for the admin to disable/enable
>> energy aware scheduling(EAS). EAS is enabled only if few conditions are
>> met by the platform. They are, asymmetric CPU capacity, no SMT,
>> valid cpufreq policy, frequency invariant load tracking. It is possible
>> platform when booting may not have EAS capability, but can do that after.
>> For example, changing/registering the cpufreq policy.
>>
>> At present, though platform doesn't support EAS, this sysctl is still
>> present and it ends up calling rebuild of sched domain on write to 1 and
>> NOP when writing to 0. That is confusing and un-necessary.
>>
> 

Hi Valentin, Thanks for taking a look at this patch.

> But why would you write to it in the first place? Or do you mean to use
> this as an indicator for userspace that EAS is supported?
> 

Since this sysctl is present and its value being 1, it gives the 
impression to the user that EAS is supported when it is not. 
So its an attempt to correct that part. 

So, yes, this can be an indicator whether platform can do EAS at 
the moment or platform can do EAS and admin has explicitly disabled it.