| 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
| ||
|
Date: Wed, 07 Oct 2015 17:31:25 -0400
From: Prarit Bhargava <prarit@...hat.com>
To: Doug Smythies <dsmythies@...us.net>
CC: "'Kristen Carlson Accardi'" <kristen@...ux.intel.com>,
linux-kernel@...r.kernel.org,
"'Viresh Kumar'" <viresh.kumar@...aro.org>,
linux-pm@...r.kernel.org, "'Rafael J. Wysocki'" <rjw@...ysocki.net>
Subject: Re: [PATCH] cpufreq, intel_pstate, set max_sysfs_pct and min_sysfs_pct
on governor switch
On 10/07/2015 02:52 PM, Doug Smythies wrote:
> On 2015.10.07 08:46 Prarit Bhargava wrote:
>> On 10/07/2015 11:40 AM, Doug Smythies wrote:
>>>
>>> Do we agree or disagree that the root issue seems to be (from your test)?:
>>>
>>> \# echo 100 > /sys/devices/system/cpu/intel_pstate/min_perf_pct
>>>
>>> [ 21.483436] store_min_perf_pct[453] min_sysfs_pct = 100
>>> [ 21.489373] store_min_perf_pct[456] min_perf_pct = 100
>>> [ 21.495203] store_min_perf_pct[459] min_perf_pct = 100
>>> [ 21.501050] store_min_perf_pct[462] min_perf_pct = 100
>>
>> Yep, and it appears to be done by default in Fedora & RHEL :/ ... the issue is
>> still the same IMO that min_sysfs_pct & max_sysfs_pct are not cleared on a
>> governor switch.
>
> Clearing them will break some other things. For example, and as
> shown in my original reply, resume from suspend.
>
> Why? Because, at least on my computer, the governor is changed to
> "performance" during suspend, and the "powersave" governor is
> restored sometime during resume. The users wants the settings they had
> before the suspend.
>
Looking at this in more detail after having tested on a Intel(R) Core(TM)
i7-2600 CPU @ 3.40GHz in Fedora and RHEL.
I have a feeling that the switch you're seeing (poweersave->performance, suspend
... resume, performance->powersave) is occurring in userspace, and not as a
result of the kernel. IMO if userspace changes the governor, all bets are off
on maintaining max_sysfs_pct and min_sysfs_pct.
Here's something I cannot figure out (because I do not have an Ubuntu install).
*Why* is Ubuntu making the governor switch during suspend/resume? Is it
because of archaic brokeness they were trying to paper over?
> Continuing with that printk debug kernel from earlier:
>
> pm-suspend:
>
> [12599.912028] intel_pstate_set_policy[1001] min_perf_pct = 100
> [12599.913781] intel_pstate_set_policy[1001] min_perf_pct = 100
> [12599.915343] intel_pstate_set_policy[1001] min_perf_pct = 100
> [12599.916877] intel_pstate_set_policy[1001] min_perf_pct = 100
> [12599.918444] intel_pstate_set_policy[1001] min_perf_pct = 100
> [12599.919686] intel_pstate_set_policy[1001] min_perf_pct = 100
> [12599.920932] intel_pstate_set_policy[1001] min_perf_pct = 100
> [12599.922191] intel_pstate_set_policy[1001] min_perf_pct = 100
>
> Then push the power button, i.e. resume:
>
> [12609.953358] intel_pstate_set_policy[1020] min_perf_pct = 50
> [12609.953360] intel_pstate_set_policy[1023] min_perf_pct = 50
> [12609.953361] intel_pstate_set_policy[1028] min_perf_pct = 50
> [12609.953796] intel_pstate_set_policy[1020] min_perf_pct = 50
> [12609.953797] intel_pstate_set_policy[1023] min_perf_pct = 50
> [12609.953798] intel_pstate_set_policy[1028] min_perf_pct = 50
> [12609.954209] intel_pstate_set_policy[1020] min_perf_pct = 50
> [12609.954210] intel_pstate_set_policy[1023] min_perf_pct = 50
> [12609.954211] intel_pstate_set_policy[1028] min_perf_pct = 50
> [12609.954619] intel_pstate_set_policy[1020] min_perf_pct = 50
> [12609.954620] intel_pstate_set_policy[1023] min_perf_pct = 50
> [12609.954621] intel_pstate_set_policy[1028] min_perf_pct = 50
> [12609.955028] intel_pstate_set_policy[1020] min_perf_pct = 50
> [12609.955029] intel_pstate_set_policy[1023] min_perf_pct = 50
> [12609.955030] intel_pstate_set_policy[1028] min_perf_pct = 50
> [12609.955431] intel_pstate_set_policy[1020] min_perf_pct = 50
> [12609.955432] intel_pstate_set_policy[1023] min_perf_pct = 50
> [12609.955433] intel_pstate_set_policy[1028] min_perf_pct = 50
> [12609.955833] intel_pstate_set_policy[1020] min_perf_pct = 50
> [12609.955834] intel_pstate_set_policy[1023] min_perf_pct = 50
> [12609.955835] intel_pstate_set_policy[1028] min_perf_pct = 50
> [12609.956234] intel_pstate_set_policy[1020] min_perf_pct = 50
> [12609.956235] intel_pstate_set_policy[1023] min_perf_pct = 50
> [12609.956235] intel_pstate_set_policy[1028] min_perf_pct = 50
>
> The below is copied from my original reply:
>
> Before Patch, I get:
>
> root@s15:/home/doug/temp# grep . /sys/devices/system/cpu/intel_pstate/*_perf_*
> /sys/devices/system/cpu/intel_pstate/max_perf_pct:80
> /sys/devices/system/cpu/intel_pstate/min_perf_pct:50
> root@s15:/home/doug/temp# pm-suspend
> ...
> root@s15:/home/doug/temp# grep . /sys/devices/system/cpu/intel_pstate/*_perf_*
> /sys/devices/system/cpu/intel_pstate/max_perf_pct:80
> /sys/devices/system/cpu/intel_pstate/min_perf_pct:50
>
> After Patch, I get:
>
> root@s15:/home/doug/temp# grep . /sys/devices/system/cpu/intel_pstate/*_perf_*
> /sys/devices/system/cpu/intel_pstate/max_perf_pct:80
> /sys/devices/system/cpu/intel_pstate/min_perf_pct:50
> root@s15:/home/doug/temp# pm-suspend
> ...
> root@s15:/home/doug/temp# grep . /sys/devices/system/cpu/intel_pstate/*_perf_*
> /sys/devices/system/cpu/intel_pstate/max_perf_pct:100
> /sys/devices/system/cpu/intel_pstate/min_perf_pct:42
Here's what I get after the patch (again, on Fedora which appears to let the
kernel do it's thing during suspend/resume) on the same processor you are using
(a Sandybridge, Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz), and using the
powersave governor,
[root@...el-skylake-y-01 ~]# cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 0.97 ms.
hardware limits: 400 MHz - 2.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.70 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
boost state support:
Supported: yes
Active: yes
[root@...el-skylake-y-01 ~]# cat /sys/devices/system/cpu/intel_pstate/*_perf_pct
100
14
[root@...el-skylake-y-01 ~]# echo devices > /sys/power/pm_test; echo platform >
/sys/power/disk; sleep 1; echo disk > /sys/power/state
[root@...el-skylake-y-01 ~]# cat /sys/devices/system/cpu/intel_pstate/*_perf_pct
100
14
Even if I manually change the max & min,
[root@...el-skylake-y-01 ~]# echo 80 >
/sys/devices/system/cpu/intel_pstate/max_perf_pct
[root@...el-skylake-y-01 ~]# echo 50 >
/sys/devices/system/cpu/intel_pstate/min_perf_pct
[root@...el-skylake-y-01 ~]# cat /sys/devices/system/cpu/intel_pstate/*_perf_pct
80
50
[root@...el-skylake-y-01 ~]# echo devices > /sys/power/pm_test; echo platform >
/sys/power/disk; sleep 1; echo disk > /sys/power/state
[root@...el-skylake-y-01 ~]# cat /sys/devices/system/cpu/intel_pstate/*_perf_pct
80
50
[root@...el-skylake-y-01 ~]#
Everything works. It doesn't work on Ubuntu because userspace is doing
something weird. Let's figure out why that is -- anyone know who works on s/r @
Ubuntu?
P.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists