linux-kernel - Re: [PATCH v3] sched/topology: remove sysctl_sched_energy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c6dd2ec-b9a9-b364-5a29-05336127e519@linux.vnet.ibm.com>
Date:   Thu, 14 Sep 2023 23:26:55 +0530
From:   Shrikanth Hegde <sshegde@...ux.vnet.ibm.com>
To:     Valentin Schneider <vschneid@...hat.com>
Cc:     dietmar.eggemann@....com, linux-kernel@...r.kernel.org,
        ionela.voinescu@....com, quentin.perret@....com,
        srikar@...ux.vnet.ibm.com, mgorman@...hsingularity.net,
        mingo@...nel.org, pierre.gondois@....com, yu.c.chen@...el.com,
        tim.c.chen@...ux.intel.com, mingo@...hat.com, peterz@...radead.org,
        vincent.guittot@...aro.org
Subject: Re: [PATCH v3] sched/topology: remove sysctl_sched_energy_aware
 depending on the architecture



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.