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] [day] [month] [year] [list]
Message-ID: <7acb0cd9-4b72-52fa-4097-72c06982410d@linux.vnet.ibm.com>
Date:   Wed, 30 Aug 2023 21:32:35 +0530
From:   Shrikanth Hegde <sshegde@...ux.vnet.ibm.com>
To:     Chen Yu <yu.c.chen@...el.com>
Cc:     mingo@...hat.com, peterz@...radead.org, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, vschneid@...hat.com,
        linux-kernel@...r.kernel.org, ionela.voinescu@....com,
        quentin.perret@....com, srikar@...ux.vnet.ibm.com,
        mgorman@...hsingularity.net, mingo@...nel.org
Subject: Re: [PATCH] sched/topology: remove sysctl_sched_energy_aware
 depending on the architecture



On 8/30/23 6:46 PM, Chen Yu wrote:
> Hi Shrikanth,
> 
> On 2023-08-29 at 12:20:40 +0530, Shrikanth Hegde wrote:
>> Currently sysctl_sched_energy_aware doesn't alter the said behaviour on
>> some of the architectures. IIUC its meant to either force rebuild the
>> perf domains or cleanup the perf domains by echoing 1 or 0 respectively.
>>
>> perf domains are not built when there is SMT, or when there is no
>> Asymmetric CPU topologies or when there is no frequency invariance.
>> Since such cases EAS is not set and perf domains are not built. By
>> changing the values of sysctl_sched_energy_aware, its not possible to
>> force build the perf domains. Hence remove this sysctl on such platforms
>> that dont support it at boot. Some of the settings can be changed later
>> such as smt_active by offlining the CPU's, In those cases
>> build_perf_domains returns true, in that case re-enable the sysctl.
>>
>> Signed-off-by: Shrikanth Hegde <sshegde@...ux.vnet.ibm.com>
>>
> 
> [snip...]
> 
>> @@ -380,15 +400,11 @@ static bool build_perf_domains(const struct cpumask *cpu_map)
>>  	struct cpufreq_policy *policy;
>>  	struct cpufreq_governor *gov;
>>
>> -	if (!sysctl_sched_energy_aware)
>> -		goto free;
>> -
> 
> I tried to ramp up the EAS and maybe I overlooked it, why do we remove above
> check? If the system boots with EAS enabled and sysctl_sched_energy_aware
> set to 1, then the user wants to disable EAS then changing sysctl_sched_energy_aware
> to 0. Without above check, how could the perf domain be freed?
> 

Thank you very much Chen Yu, for taking a look. I had missed that case.

The reason for removing it was, conditions which are checked while doing
build_perf_domains can be changed after system boot. like by off-lining the SMT
siblings, sched_smt_active can be false, it is possible in future for the other
conditions to be false as well. In that case, having the sysctl check wouldn't
allow it to build the perf domains.

Since any change in this sysctl, will set sched_energy_update. That can be used
in combination to detect whether change is coming due to sysctl change or due
to system becoming capable of doing perf domains.


Something like below would work. 

+       if (!sysctl_sched_energy_aware && sched_energy_update)
+               goto free;

This will introduce another issue, that it will remove the sysctl after setting
it to 0. Have taken care of that with below code change.


@@ -349,7 +349,16 @@ static void sched_energy_set(bool has_eas)
                        pr_info("%s: stopping EAS\n", __func__);
                static_branch_disable_cpuslocked(&sched_energy_present);
 #ifdef CONFIG_PROC_SYSCTL
-               unregister_sysctl_table(sysctl_eas_header);
+               /*
+                * if the architecture supports EAS and forcefully
+                * perf domains are destroyed, there should be a sysctl
+                * to eanble it later. If this was due to dynamic system
+                * change such as SMT<->NON_SMT then remove sysctl.
+                */
+               if (sysctl_eas_header && !sched_energy_update) {
+                       unregister_sysctl_table(sysctl_eas_header);
+                       sysctl_eas_header = NULL;
+               }
 #endif
                sysctl_sched_energy_aware = 0;
        } else if (has_eas && !static_branch_unlikely(&sched_energy_present)) {
@@ -357,7 +366,8 @@ static void sched_energy_set(bool has_eas)
                        pr_info("%s: starting EAS\n", __func__);
                static_branch_enable_cpuslocked(&sched_energy_present);
 #ifdef CONFIG_PROC_SYSCTL
-               sysctl_eas_header = register_sysctl("kernel", sched_energy_aware_sysctls);
+               if (!sysctl_eas_header)
+                       sysctl_eas_header = register_sysctl("kernel", sched_energy_aware_sysctls);
 #endif
                sysctl_sched_energy_aware = 1;
        }



Different Cases:

Case1. system while booting has EAS capability, sysctl will be set 1. Hence
perf domains will be built On changing the sysctl to 0, above condition will be
true and hence it would be freed and sysctl will not be removed. later sysctl
is changed to 1, enabling the perf domains rebuilt again. Since sysctl is
already there, it will skip register.

Case2. System while booting doesn't have EAS Capability. Later after system
change it becomes capable of EAS. sched_energy_update is false. Hence though
sysctl is 0, will go ahead and try to enable eas. if has_eas  is true, then
sysctl will be registered. After that it any sysctl change is same as Case1.

Case3. System becomes not capable of EAS due to system change. Here since
sched_energy_update is false.  build_perf_domains return has_eas as false and
Since this is dynamic change remove the sysctl.


A bit convoluted because the design here, is considering dynamically system
becoming capable of EAS.  Will send out a V2 with the above change after some
testing (have to try with HACK since EAS is by default not enabled on power10)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ