* 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram @ 2013-06-18 15:57 Toralf Förster 2013-06-18 20:27 ` Toralf Förster 2013-06-18 22:05 ` Rafael J. Wysocki 0 siblings, 2 replies; 44+ messages in thread From: Toralf Förster @ 2013-06-18 15:57 UTC (permalink / raw) To: cpufreq At a stable 32bit Gentoo Linux with a i5 processor (2.6 GHZ max, 3.1 GHz boost) I've to change the governor after a s2ram all 4 cores from "ondemand" to "performance" and back to "ondemand", otherwise cpu1 till cpu3 would stay after s2ram at 2.6 GHz (whilst cpu0 is at the expected 800 MHz if no load is at the system) - FWIW I do set ignore_nice to "1". 3.9.6 is ok, the bug was introduces somewhere in 3.10-rcX. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-18 15:57 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram Toralf Förster @ 2013-06-18 20:27 ` Toralf Förster 2013-06-18 22:05 ` Rafael J. Wysocki 1 sibling, 0 replies; 44+ messages in thread From: Toralf Förster @ 2013-06-18 20:27 UTC (permalink / raw) To: cpufreq On 06/18/2013 05:57 PM, Toralf Förster wrote: > At a stable 32bit Gentoo Linux with a i5 processor (2.6 GHZ max, 3.1 GHz > boost) I've to change the governor after a s2ram all 4 cores from > "ondemand" to "performance" and back to "ondemand", otherwise cpu1 till > cpu3 would stay after s2ram at 2.6 GHz (whilst cpu0 is at the expected > 800 MHz if no load is at the system) - FWIW I do set ignore_nice to "1". > > 3.9.6 is ok, the bug was introduces somewhere in 3.10-rcX. > FWIW the following commands circumvents that issue : # for i in $(seq 1 3); do echo performance > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done # for i in $(seq 1 3); do echo ondemand > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done cpu0 is unaffected -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-18 15:57 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram Toralf Förster 2013-06-18 20:27 ` Toralf Förster @ 2013-06-18 22:05 ` Rafael J. Wysocki 2013-06-26 18:36 ` Toralf Förster 1 sibling, 1 reply; 44+ messages in thread From: Rafael J. Wysocki @ 2013-06-18 22:05 UTC (permalink / raw) To: Toralf Förster; +Cc: cpufreq On Tuesday, June 18, 2013 05:57:36 PM Toralf Förster wrote: > At a stable 32bit Gentoo Linux with a i5 processor (2.6 GHZ max, 3.1 GHz > boost) I've to change the governor after a s2ram all 4 cores from > "ondemand" to "performance" and back to "ondemand", otherwise cpu1 till > cpu3 would stay after s2ram at 2.6 GHz (whilst cpu0 is at the expected > 800 MHz if no load is at the system) - FWIW I do set ignore_nice to "1". > > 3.9.6 is ok, the bug was introduces somewhere in 3.10-rcX. Hmm. This looks like something unrelated to the previous reports. How do you check the frequencies? Does that happen every time? If so, any chance to bisect driver/cpufreq changes between 3.9 and now? Does it work without ignore_nice? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-18 22:05 ` Rafael J. Wysocki @ 2013-06-26 18:36 ` Toralf Förster 2013-06-26 19:12 ` Rafael J. Wysocki 0 siblings, 1 reply; 44+ messages in thread From: Toralf Förster @ 2013-06-26 18:36 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: cpufreq On 06/19/2013 12:05 AM, Rafael J. Wysocki wrote: > Hmm. This looks like something unrelated to the previous reports. yes > How do you check the frequencies? much more significant is the temperature : $> cat /sys/devices/system/cpu/cpu\?/thermal_throttle/package_power_limit_count /proc/acpi/ibm/fan /sys/class/hwmon/hwmon\?/device/temp\?_input' - it is around 49° if just 4 BOINC childs are running at nice level -19, but it is above 65°C if the issue exists. And in hat case I just do run $> for g in performance ondemand; do for i in 0 1 2 3; do echo $g > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done; done; echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice and the system is back to normal. > Does that happen every time? If so, any chance to bisect driver/cpufreq > changes between 3.9 and now? first bisect attempts failed. I realized that the issue only occurs if the power is plugged in. If the system is running on battery the issue doesn't occurred (I checked it more than once) > Does it work without ignore_nice? Seems not to be related to that. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-26 18:36 ` Toralf Förster @ 2013-06-26 19:12 ` Rafael J. Wysocki 2013-06-27 4:10 ` Viresh Kumar 0 siblings, 1 reply; 44+ messages in thread From: Rafael J. Wysocki @ 2013-06-26 19:12 UTC (permalink / raw) To: Toralf Förster; +Cc: cpufreq, Linux PM list, Viresh Kumar On Wednesday, June 26, 2013 08:36:18 PM Toralf Förster wrote: > On 06/19/2013 12:05 AM, Rafael J. Wysocki wrote: > > Hmm. This looks like something unrelated to the previous reports. > > yes > > > How do you check the frequencies? > > much more significant is the temperature : > > $> cat /sys/devices/system/cpu/cpu\?/thermal_throttle/package_power_limit_count /proc/acpi/ibm/fan /sys/class/hwmon/hwmon\?/device/temp\?_input' > > - it is around 49° if just 4 BOINC childs are running at nice level -19, but it is above 65°C if the issue exists. And in hat case I just do run > > $> for g in performance ondemand; do for i in 0 1 2 3; do echo $g > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done; done; echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice > > and the system is back to normal. > > > Does that happen every time? If so, any chance to bisect driver/cpufreq > > changes between 3.9 and now? > > first bisect attempts failed. I realized that the issue only occurs if the power is plugged in. If the system is running on battery the issue doesn't occurred (I checked it more than once) > > > Does it work without ignore_nice? > Seems not to be related to that. Well, I'm not aware of any recent changes in cpufreq that would make things work differently depending on whether or not AC power is used. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-26 19:12 ` Rafael J. Wysocki @ 2013-06-27 4:10 ` Viresh Kumar 2013-06-27 18:00 ` Toralf Förster 0 siblings, 1 reply; 44+ messages in thread From: Viresh Kumar @ 2013-06-27 4:10 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Toralf Förster, cpufreq, Linux PM list On 27 June 2013 00:42, Rafael J. Wysocki <rjw@sisk.pl> wrote: > Well, I'm not aware of any recent changes in cpufreq that would make things > work differently depending on whether or not AC power is used. Toralf, It would be helpful if you can do git bisect and let us know which patch created this problem. Otherwise its very difficult to trace it. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-27 4:10 ` Viresh Kumar @ 2013-06-27 18:00 ` Toralf Förster 2013-06-28 3:44 ` Viresh Kumar 0 siblings, 1 reply; 44+ messages in thread From: Toralf Förster @ 2013-06-27 18:00 UTC (permalink / raw) To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list On 06/27/2013 06:10 AM, Viresh Kumar wrote: > On 27 June 2013 00:42, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> Well, I'm not aware of any recent changes in cpufreq that would make things >> work differently depending on whether or not AC power is used. > > Toralf, > > It would be helpful if you can do git bisect and let us know which patch > created this problem. Otherwise its very difficult to trace it. > Yep, but 14 commits to bisect and about 20-30 min for each - will see, when I find a time slot. Just FWIW thie following is now a good indicator for the issue - that's the picture after wakeup, where I'd expect always 800 MHz: $ sudo cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_cur_freq 800000 2601000 2601000 2601000 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-27 18:00 ` Toralf Förster @ 2013-06-28 3:44 ` Viresh Kumar 2013-06-28 15:25 ` Toralf Förster 2013-06-28 17:17 ` Toralf Förster 0 siblings, 2 replies; 44+ messages in thread From: Viresh Kumar @ 2013-06-28 3:44 UTC (permalink / raw) To: Toralf Förster; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list On 27 June 2013 23:30, Toralf Förster <toralf.foerster@gmx.de> wrote: > Yep, but 14 commits to bisect and about 20-30 min for each - will see, > when I find a time slot. Hmm.. > Just FWIW thie following is now a good indicator for the issue - that's > the picture after wakeup, where I'd expect always 800 MHz: > > $ sudo cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_cur_freq > 800000 > 2601000 > 2601000 > 2601000 Can you give dumps of complete cpufreq directories for all cpus before and after s2r. That may give us some hint about the problem. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-28 3:44 ` Viresh Kumar @ 2013-06-28 15:25 ` Toralf Förster 2013-06-29 13:30 ` Viresh Kumar 2013-06-28 17:17 ` Toralf Förster 1 sibling, 1 reply; 44+ messages in thread From: Toralf Förster @ 2013-06-28 15:25 UTC (permalink / raw) To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list [-- Attachment #1: Type: text/plain, Size: 1695 bytes --] On 06/28/2013 05:44 AM, Viresh Kumar wrote: > Can you give dumps of complete cpufreq directories for all cpus before > and after s2r. That may give us some hint about the problem. here it is: $ sudo su - n22 ~ # cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq 800000 800000 800000 800000 n22 ~ # cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_cur_freq 800000 800000 800000 800000 n22 ~ # find /sys/devices/system/cpu -type f | xargs tail -v > /tmp/before 2>/dev/null n22 ~ # Fn4 * Bringing down interface ppp0 * Running predown ... * Stopping pppd on ppp0 [ ok ] * Bringing up interface ppp0 * Starting pppd in ppp0 ... [ ok ] * received address 92.224.127.7 * WARNING: net.ppp0 has started, but is inactive n22 ~ # cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq 800000 800000 800000 800000 n22 ~ # cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_cur_freq 800000 2601000 2601000 2601000 n22 ~ # find /sys/devices/system/cpu -type f | xargs tail -v > /tmp/after 2>/dev/null n22 ~ # for g in performance ondemand; do for i in 1 2 3; do echo $g > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done; done; echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice n22 ~ # cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq800000 800000 800000 800000 n22 ~ # cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_cur_freq800000 800000 800000 800000 n22 ~ # chmod a+r /tmp/before /tmp/after -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 [-- Attachment #2: after --] [-- Type: text/plain, Size: 34758 bytes --] ==> /sys/devices/system/cpu/cpu0/cpufreq/bios_limit <== 2601000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor <== ondemand ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency <== 10000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies <== 2601000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver <== acpi-cpufreq ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors <== ondemand performance ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus <== 0 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/related_cpus <== 0 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed <== <unsupported> ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/desc <== CPUIDLE CORE POLL IDLE ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/name <== POLL ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/time <== 19239 ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/power <== 4294967295 ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/usage <== 55 ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/latency <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/desc <== MWAIT 0x00 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/name <== C1-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/time <== 924048 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/usage <== 7370 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/latency <== 2 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/desc <== MWAIT 0x01 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/name <== C1E-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/time <== 8659159 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/usage <== 18164 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/latency <== 10 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/desc <== MWAIT 0x10 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/name <== C3-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/time <== 3258501 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/usage <== 4979 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/latency <== 80 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/desc <== MWAIT 0x20 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/name <== C6-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/time <== 229632 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/usage <== 185 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/latency <== 104 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/desc <== MWAIT 0x30 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/name <== C7-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/time <== 55353981 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/usage <== 34407 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/latency <== 109 ==> /sys/devices/system/cpu/cpu0/cache/index0/size <== 32K ==> /sys/devices/system/cpu/cpu0/cache/index0/type <== Data ==> /sys/devices/system/cpu/cpu0/cache/index0/level <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index0/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index0/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index0/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu0/cache/index1/size <== 32K ==> /sys/devices/system/cpu/cpu0/cache/index1/type <== Instruction ==> /sys/devices/system/cpu/cpu0/cache/index1/level <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index1/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu0/cache/index1/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index1/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index1/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu0/cache/index2/size <== 256K ==> /sys/devices/system/cpu/cpu0/cache/index2/type <== Unified ==> /sys/devices/system/cpu/cpu0/cache/index2/level <== 2 ==> /sys/devices/system/cpu/cpu0/cache/index2/number_of_sets <== 512 ==> /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu0/cache/index2/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index2/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index2/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu0/cache/index3/size <== 3072K ==> /sys/devices/system/cpu/cpu0/cache/index3/type <== Unified ==> /sys/devices/system/cpu/cpu0/cache/index3/level <== 3 ==> /sys/devices/system/cpu/cpu0/cache/index3/number_of_sets <== 4096 ==> /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_map <== 0f ==> /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list <== 0-3 ==> /sys/devices/system/cpu/cpu0/cache/index3/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index3/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index3/ways_of_associativity <== 12 ==> /sys/devices/system/cpu/cpu0/power/control <== auto ==> /sys/devices/system/cpu/cpu0/power/async <== disabled ==> /sys/devices/system/cpu/cpu0/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/cpu0/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/cpu0/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/cpu0/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/cpu0/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/cpu0/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/cpu0/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/cpu0/uevent <== MODALIAS=x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/cpu0/topology/core_id <== 0 ==> /sys/devices/system/cpu/cpu0/topology/thread_siblings <== 03 ==> /sys/devices/system/cpu/cpu0/topology/core_siblings <== 0f ==> /sys/devices/system/cpu/cpu0/topology/core_siblings_list <== 0-3 ==> /sys/devices/system/cpu/cpu0/topology/thread_siblings_list <== 0-1 ==> /sys/devices/system/cpu/cpu0/topology/physical_package_id <== 0 ==> /sys/devices/system/cpu/cpu0/thermal_throttle/core_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu0/thermal_throttle/package_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu0/thermal_throttle/package_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu1/cpufreq/bios_limit <== 2601000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor <== ondemand ==> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency <== 10000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies <== 2601000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver <== acpi-cpufreq ==> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq <== 2601000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors <== ondemand performance ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu1/cpufreq/affected_cpus <== 1 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/related_cpus <== 1 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed <== <unsupported> ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/desc <== CPUIDLE CORE POLL IDLE ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/name <== POLL ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/time <== 61773 ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/power <== 4294967295 ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/usage <== 27 ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/latency <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/desc <== MWAIT 0x00 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/name <== C1-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/time <== 259855 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/usage <== 4464 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/latency <== 2 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/desc <== MWAIT 0x01 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/name <== C1E-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/time <== 7498088 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/usage <== 9108 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/latency <== 10 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/desc <== MWAIT 0x10 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/name <== C3-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/time <== 3915900 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/usage <== 2583 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/latency <== 80 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/desc <== MWAIT 0x20 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/name <== C6-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/time <== 163650 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/usage <== 73 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/latency <== 104 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/desc <== MWAIT 0x30 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/name <== C7-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/time <== 56007989 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/usage <== 10807 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/latency <== 109 ==> /sys/devices/system/cpu/cpu1/cache/index0/size <== 32K ==> /sys/devices/system/cpu/cpu1/cache/index0/type <== Data ==> /sys/devices/system/cpu/cpu1/cache/index0/level <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index0/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu1/cache/index0/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index0/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index0/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu1/cache/index1/size <== 32K ==> /sys/devices/system/cpu/cpu1/cache/index1/type <== Instruction ==> /sys/devices/system/cpu/cpu1/cache/index1/level <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index1/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu1/cache/index1/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index1/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index1/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu1/cache/index2/size <== 256K ==> /sys/devices/system/cpu/cpu1/cache/index2/type <== Unified ==> /sys/devices/system/cpu/cpu1/cache/index2/level <== 2 ==> /sys/devices/system/cpu/cpu1/cache/index2/number_of_sets <== 512 ==> /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu1/cache/index2/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index2/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index2/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu1/cache/index3/size <== 3072K ==> /sys/devices/system/cpu/cpu1/cache/index3/type <== Unified ==> /sys/devices/system/cpu/cpu1/cache/index3/level <== 3 ==> /sys/devices/system/cpu/cpu1/cache/index3/number_of_sets <== 4096 ==> /sys/devices/system/cpu/cpu1/cache/index3/shared_cpu_map <== 0f ==> /sys/devices/system/cpu/cpu1/cache/index3/shared_cpu_list <== 0-3 ==> /sys/devices/system/cpu/cpu1/cache/index3/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index3/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index3/ways_of_associativity <== 12 ==> /sys/devices/system/cpu/cpu1/power/control <== auto ==> /sys/devices/system/cpu/cpu1/power/async <== disabled ==> /sys/devices/system/cpu/cpu1/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/cpu1/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/cpu1/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/cpu1/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/cpu1/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/cpu1/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/cpu1/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/cpu1/online <== 1 ==> /sys/devices/system/cpu/cpu1/uevent <== MODALIAS=x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/cpu1/topology/core_id <== 0 ==> /sys/devices/system/cpu/cpu1/topology/thread_siblings <== 03 ==> /sys/devices/system/cpu/cpu1/topology/core_siblings <== 0f ==> /sys/devices/system/cpu/cpu1/topology/core_siblings_list <== 0-3 ==> /sys/devices/system/cpu/cpu1/topology/thread_siblings_list <== 0-1 ==> /sys/devices/system/cpu/cpu1/topology/physical_package_id <== 0 ==> /sys/devices/system/cpu/cpu1/thermal_throttle/core_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu1/thermal_throttle/package_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu1/thermal_throttle/core_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu1/thermal_throttle/package_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu2/cpufreq/bios_limit <== 2601000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor <== ondemand ==> /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_transition_latency <== 10000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_available_frequencies <== 2601000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_driver <== acpi-cpufreq ==> /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_cur_freq <== 2601000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_available_governors <== ondemand performance ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu2/cpufreq/affected_cpus <== 2 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/related_cpus <== 2 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_setspeed <== <unsupported> ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/desc <== CPUIDLE CORE POLL IDLE ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/name <== POLL ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/time <== 15532 ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/power <== 4294967295 ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/usage <== 36 ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/latency <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/desc <== MWAIT 0x00 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/name <== C1-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/time <== 425542 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/usage <== 7866 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/latency <== 2 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/desc <== MWAIT 0x01 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/name <== C1E-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/time <== 8230973 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/usage <== 8798 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/latency <== 10 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/desc <== MWAIT 0x10 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/name <== C3-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/time <== 4179929 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/usage <== 2322 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/latency <== 80 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/desc <== MWAIT 0x20 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/name <== C6-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/time <== 195865 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/usage <== 68 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/latency <== 104 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/desc <== MWAIT 0x30 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/name <== C7-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/time <== 56796175 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/usage <== 10190 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/latency <== 109 ==> /sys/devices/system/cpu/cpu2/cache/index0/size <== 32K ==> /sys/devices/system/cpu/cpu2/cache/index0/type <== Data ==> /sys/devices/system/cpu/cpu2/cache/index0/level <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index0/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index0/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu2/cache/index0/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu2/cache/index0/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index0/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index0/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu2/cache/index1/size <== 32K ==> /sys/devices/system/cpu/cpu2/cache/index1/type <== Instruction ==> /sys/devices/system/cpu/cpu2/cache/index1/level <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index1/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index1/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu2/cache/index1/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu2/cache/index1/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index1/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index1/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu2/cache/index2/size <== 256K ==> /sys/devices/system/cpu/cpu2/cache/index2/type <== Unified ==> /sys/devices/system/cpu/cpu2/cache/index2/level <== 2 ==> /sys/devices/system/cpu/cpu2/cache/index2/number_of_sets <== 512 ==> /sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu2/cache/index2/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index2/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index2/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu2/cache/index3/size <== 3072K ==> /sys/devices/system/cpu/cpu2/cache/index3/type <== Unified ==> /sys/devices/system/cpu/cpu2/cache/index3/level <== 3 ==> /sys/devices/system/cpu/cpu2/cache/index3/number_of_sets <== 4096 ==> /sys/devices/system/cpu/cpu2/cache/index3/shared_cpu_map <== 0f ==> /sys/devices/system/cpu/cpu2/cache/index3/shared_cpu_list <== 0-3 ==> /sys/devices/system/cpu/cpu2/cache/index3/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index3/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index3/ways_of_associativity <== 12 ==> /sys/devices/system/cpu/cpu2/power/control <== auto ==> /sys/devices/system/cpu/cpu2/power/async <== disabled ==> /sys/devices/system/cpu/cpu2/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/cpu2/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/cpu2/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/cpu2/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/cpu2/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/cpu2/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/cpu2/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/cpu2/online <== 1 ==> /sys/devices/system/cpu/cpu2/uevent <== MODALIAS=x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/cpu2/topology/core_id <== 1 ==> /sys/devices/system/cpu/cpu2/topology/thread_siblings <== 0c ==> /sys/devices/system/cpu/cpu2/topology/core_siblings <== 0f ==> /sys/devices/system/cpu/cpu2/topology/core_siblings_list <== 0-3 ==> /sys/devices/system/cpu/cpu2/topology/thread_siblings_list <== 2-3 ==> /sys/devices/system/cpu/cpu2/topology/physical_package_id <== 0 ==> /sys/devices/system/cpu/cpu2/thermal_throttle/core_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu2/thermal_throttle/package_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu2/thermal_throttle/core_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu2/thermal_throttle/package_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu3/cpufreq/bios_limit <== 2601000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor <== ondemand ==> /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_transition_latency <== 10000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_available_frequencies <== 2601000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver <== acpi-cpufreq ==> /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq <== 2601000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors <== ondemand performance ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu3/cpufreq/affected_cpus <== 3 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/related_cpus <== 3 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_setspeed <== <unsupported> ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/desc <== CPUIDLE CORE POLL IDLE ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/name <== POLL ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/time <== 2323 ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/power <== 4294967295 ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/usage <== 28 ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/latency <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/desc <== MWAIT 0x00 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/name <== C1-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/time <== 456731 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/usage <== 7560 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/latency <== 2 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/desc <== MWAIT 0x01 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/name <== C1E-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/time <== 5585596 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/usage <== 6373 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/latency <== 10 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/desc <== MWAIT 0x10 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/name <== C3-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/time <== 3177689 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/usage <== 1769 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/latency <== 80 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/desc <== MWAIT 0x20 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/name <== C6-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/time <== 73846 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/usage <== 38 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/latency <== 104 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/desc <== MWAIT 0x30 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/name <== C7-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/time <== 56910450 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/usage <== 9384 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/latency <== 109 ==> /sys/devices/system/cpu/cpu3/cache/index0/size <== 32K ==> /sys/devices/system/cpu/cpu3/cache/index0/type <== Data ==> /sys/devices/system/cpu/cpu3/cache/index0/level <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index0/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index0/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu3/cache/index0/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu3/cache/index0/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index0/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index0/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu3/cache/index1/size <== 32K ==> /sys/devices/system/cpu/cpu3/cache/index1/type <== Instruction ==> /sys/devices/system/cpu/cpu3/cache/index1/level <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index1/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu3/cache/index1/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index1/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index1/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu3/cache/index2/size <== 256K ==> /sys/devices/system/cpu/cpu3/cache/index2/type <== Unified ==> /sys/devices/system/cpu/cpu3/cache/index2/level <== 2 ==> /sys/devices/system/cpu/cpu3/cache/index2/number_of_sets <== 512 ==> /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu3/cache/index2/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index2/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index2/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu3/cache/index3/size <== 3072K ==> /sys/devices/system/cpu/cpu3/cache/index3/type <== Unified ==> /sys/devices/system/cpu/cpu3/cache/index3/level <== 3 ==> /sys/devices/system/cpu/cpu3/cache/index3/number_of_sets <== 4096 ==> /sys/devices/system/cpu/cpu3/cache/index3/shared_cpu_map <== 0f ==> /sys/devices/system/cpu/cpu3/cache/index3/shared_cpu_list <== 0-3 ==> /sys/devices/system/cpu/cpu3/cache/index3/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index3/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index3/ways_of_associativity <== 12 ==> /sys/devices/system/cpu/cpu3/power/control <== auto ==> /sys/devices/system/cpu/cpu3/power/async <== disabled ==> /sys/devices/system/cpu/cpu3/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/cpu3/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/cpu3/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/cpu3/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/cpu3/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/cpu3/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/cpu3/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/cpu3/online <== 1 ==> /sys/devices/system/cpu/cpu3/uevent <== MODALIAS=x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/cpu3/topology/core_id <== 1 ==> /sys/devices/system/cpu/cpu3/topology/thread_siblings <== 0c ==> /sys/devices/system/cpu/cpu3/topology/core_siblings <== 0f ==> /sys/devices/system/cpu/cpu3/topology/core_siblings_list <== 0-3 ==> /sys/devices/system/cpu/cpu3/topology/thread_siblings_list <== 2-3 ==> /sys/devices/system/cpu/cpu3/topology/physical_package_id <== 0 ==> /sys/devices/system/cpu/cpu3/thermal_throttle/core_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu3/thermal_throttle/package_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu3/thermal_throttle/core_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu3/thermal_throttle/package_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpufreq/boost <== 1 ==> /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias <== 0 ==> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate <== 10000 ==> /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy <== 1 ==> /sys/devices/system/cpu/cpufreq/ondemand/up_threshold <== 95 ==> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate_min <== 10000 ==> /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor <== 1 ==> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice <== 1 ==> /sys/devices/system/cpu/cpuidle/current_driver <== intel_idle ==> /sys/devices/system/cpu/cpuidle/current_governor_ro <== menu ==> /sys/devices/system/cpu/power/control <== auto ==> /sys/devices/system/cpu/power/async <== disabled ==> /sys/devices/system/cpu/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/modalias <== x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/kernel_max <== 7 ==> /sys/devices/system/cpu/possible <== 0-7 ==> /sys/devices/system/cpu/online <== 0-3 ==> /sys/devices/system/cpu/offline <== 4-7 ==> /sys/devices/system/cpu/uevent <== ==> /sys/devices/system/cpu/present <== 0-3 [-- Attachment #3: before --] [-- Type: text/plain, Size: 34755 bytes --] ==> /sys/devices/system/cpu/cpu0/cpufreq/bios_limit <== 2601000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor <== ondemand ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency <== 10000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies <== 2601000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver <== acpi-cpufreq ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors <== ondemand performance ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus <== 0 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu0/cpufreq/related_cpus <== 0 ==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed <== <unsupported> ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/desc <== CPUIDLE CORE POLL IDLE ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/name <== POLL ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/time <== 19233 ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/power <== 4294967295 ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/usage <== 54 ==> /sys/devices/system/cpu/cpu0/cpuidle/state0/latency <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/desc <== MWAIT 0x00 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/name <== C1-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/time <== 919026 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/usage <== 7243 ==> /sys/devices/system/cpu/cpu0/cpuidle/state1/latency <== 2 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/desc <== MWAIT 0x01 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/name <== C1E-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/time <== 8630346 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/usage <== 17935 ==> /sys/devices/system/cpu/cpu0/cpuidle/state2/latency <== 10 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/desc <== MWAIT 0x10 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/name <== C3-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/time <== 3240741 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/usage <== 4955 ==> /sys/devices/system/cpu/cpu0/cpuidle/state3/latency <== 80 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/desc <== MWAIT 0x20 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/name <== C6-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/time <== 226879 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/usage <== 184 ==> /sys/devices/system/cpu/cpu0/cpuidle/state4/latency <== 104 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/desc <== MWAIT 0x30 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/name <== C7-SNB ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/time <== 52170100 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/disable <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/power <== 0 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/usage <== 33875 ==> /sys/devices/system/cpu/cpu0/cpuidle/state5/latency <== 109 ==> /sys/devices/system/cpu/cpu0/cache/index0/size <== 32K ==> /sys/devices/system/cpu/cpu0/cache/index0/type <== Data ==> /sys/devices/system/cpu/cpu0/cache/index0/level <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index0/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index0/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index0/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu0/cache/index1/size <== 32K ==> /sys/devices/system/cpu/cpu0/cache/index1/type <== Instruction ==> /sys/devices/system/cpu/cpu0/cache/index1/level <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index1/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu0/cache/index1/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index1/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index1/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu0/cache/index2/size <== 256K ==> /sys/devices/system/cpu/cpu0/cache/index2/type <== Unified ==> /sys/devices/system/cpu/cpu0/cache/index2/level <== 2 ==> /sys/devices/system/cpu/cpu0/cache/index2/number_of_sets <== 512 ==> /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu0/cache/index2/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index2/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index2/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu0/cache/index3/size <== 3072K ==> /sys/devices/system/cpu/cpu0/cache/index3/type <== Unified ==> /sys/devices/system/cpu/cpu0/cache/index3/level <== 3 ==> /sys/devices/system/cpu/cpu0/cache/index3/number_of_sets <== 4096 ==> /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_map <== 0f ==> /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list <== 0-3 ==> /sys/devices/system/cpu/cpu0/cache/index3/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu0/cache/index3/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu0/cache/index3/ways_of_associativity <== 12 ==> /sys/devices/system/cpu/cpu0/power/control <== auto ==> /sys/devices/system/cpu/cpu0/power/async <== disabled ==> /sys/devices/system/cpu/cpu0/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/cpu0/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/cpu0/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/cpu0/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/cpu0/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/cpu0/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/cpu0/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/cpu0/uevent <== MODALIAS=x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/cpu0/topology/core_id <== 0 ==> /sys/devices/system/cpu/cpu0/topology/thread_siblings <== 03 ==> /sys/devices/system/cpu/cpu0/topology/core_siblings <== 0f ==> /sys/devices/system/cpu/cpu0/topology/core_siblings_list <== 0-3 ==> /sys/devices/system/cpu/cpu0/topology/thread_siblings_list <== 0-1 ==> /sys/devices/system/cpu/cpu0/topology/physical_package_id <== 0 ==> /sys/devices/system/cpu/cpu0/thermal_throttle/core_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu0/thermal_throttle/package_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu0/thermal_throttle/package_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu1/cpufreq/bios_limit <== 2601000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor <== ondemand ==> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency <== 10000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies <== 2601000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver <== acpi-cpufreq ==> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors <== ondemand performance ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu1/cpufreq/affected_cpus <== 1 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu1/cpufreq/related_cpus <== 1 ==> /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed <== <unsupported> ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/desc <== CPUIDLE CORE POLL IDLE ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/name <== POLL ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/time <== 61747 ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/power <== 4294967295 ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/usage <== 26 ==> /sys/devices/system/cpu/cpu1/cpuidle/state0/latency <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/desc <== MWAIT 0x00 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/name <== C1-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/time <== 256430 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/usage <== 4418 ==> /sys/devices/system/cpu/cpu1/cpuidle/state1/latency <== 2 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/desc <== MWAIT 0x01 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/name <== C1E-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/time <== 7489672 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/usage <== 9076 ==> /sys/devices/system/cpu/cpu1/cpuidle/state2/latency <== 10 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/desc <== MWAIT 0x10 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/name <== C3-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/time <== 3911044 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/usage <== 2572 ==> /sys/devices/system/cpu/cpu1/cpuidle/state3/latency <== 80 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/desc <== MWAIT 0x20 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/name <== C6-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/time <== 163650 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/usage <== 73 ==> /sys/devices/system/cpu/cpu1/cpuidle/state4/latency <== 104 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/desc <== MWAIT 0x30 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/name <== C7-SNB ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/time <== 52737221 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/disable <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/power <== 0 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/usage <== 10540 ==> /sys/devices/system/cpu/cpu1/cpuidle/state5/latency <== 109 ==> /sys/devices/system/cpu/cpu1/cache/index0/size <== 32K ==> /sys/devices/system/cpu/cpu1/cache/index0/type <== Data ==> /sys/devices/system/cpu/cpu1/cache/index0/level <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index0/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu1/cache/index0/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index0/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index0/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu1/cache/index1/size <== 32K ==> /sys/devices/system/cpu/cpu1/cache/index1/type <== Instruction ==> /sys/devices/system/cpu/cpu1/cache/index1/level <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index1/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu1/cache/index1/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index1/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index1/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu1/cache/index2/size <== 256K ==> /sys/devices/system/cpu/cpu1/cache/index2/type <== Unified ==> /sys/devices/system/cpu/cpu1/cache/index2/level <== 2 ==> /sys/devices/system/cpu/cpu1/cache/index2/number_of_sets <== 512 ==> /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map <== 03 ==> /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list <== 0-1 ==> /sys/devices/system/cpu/cpu1/cache/index2/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index2/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index2/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu1/cache/index3/size <== 3072K ==> /sys/devices/system/cpu/cpu1/cache/index3/type <== Unified ==> /sys/devices/system/cpu/cpu1/cache/index3/level <== 3 ==> /sys/devices/system/cpu/cpu1/cache/index3/number_of_sets <== 4096 ==> /sys/devices/system/cpu/cpu1/cache/index3/shared_cpu_map <== 0f ==> /sys/devices/system/cpu/cpu1/cache/index3/shared_cpu_list <== 0-3 ==> /sys/devices/system/cpu/cpu1/cache/index3/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu1/cache/index3/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu1/cache/index3/ways_of_associativity <== 12 ==> /sys/devices/system/cpu/cpu1/power/control <== auto ==> /sys/devices/system/cpu/cpu1/power/async <== disabled ==> /sys/devices/system/cpu/cpu1/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/cpu1/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/cpu1/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/cpu1/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/cpu1/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/cpu1/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/cpu1/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/cpu1/online <== 1 ==> /sys/devices/system/cpu/cpu1/uevent <== MODALIAS=x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/cpu1/topology/core_id <== 0 ==> /sys/devices/system/cpu/cpu1/topology/thread_siblings <== 03 ==> /sys/devices/system/cpu/cpu1/topology/core_siblings <== 0f ==> /sys/devices/system/cpu/cpu1/topology/core_siblings_list <== 0-3 ==> /sys/devices/system/cpu/cpu1/topology/thread_siblings_list <== 0-1 ==> /sys/devices/system/cpu/cpu1/topology/physical_package_id <== 0 ==> /sys/devices/system/cpu/cpu1/thermal_throttle/core_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu1/thermal_throttle/package_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu1/thermal_throttle/core_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu1/thermal_throttle/package_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu2/cpufreq/bios_limit <== 2601000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor <== ondemand ==> /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_transition_latency <== 10000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_available_frequencies <== 2601000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_driver <== acpi-cpufreq ==> /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_available_governors <== ondemand performance ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu2/cpufreq/affected_cpus <== 2 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu2/cpufreq/related_cpus <== 2 ==> /sys/devices/system/cpu/cpu2/cpufreq/scaling_setspeed <== <unsupported> ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/desc <== CPUIDLE CORE POLL IDLE ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/name <== POLL ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/time <== 15532 ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/power <== 4294967295 ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/usage <== 36 ==> /sys/devices/system/cpu/cpu2/cpuidle/state0/latency <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/desc <== MWAIT 0x00 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/name <== C1-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/time <== 424554 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/usage <== 7838 ==> /sys/devices/system/cpu/cpu2/cpuidle/state1/latency <== 2 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/desc <== MWAIT 0x01 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/name <== C1E-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/time <== 8228801 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/usage <== 8796 ==> /sys/devices/system/cpu/cpu2/cpuidle/state2/latency <== 10 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/desc <== MWAIT 0x10 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/name <== C3-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/time <== 4179929 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/usage <== 2322 ==> /sys/devices/system/cpu/cpu2/cpuidle/state3/latency <== 80 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/desc <== MWAIT 0x20 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/name <== C6-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/time <== 184890 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/usage <== 67 ==> /sys/devices/system/cpu/cpu2/cpuidle/state4/latency <== 104 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/desc <== MWAIT 0x30 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/name <== C7-SNB ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/time <== 53545208 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/disable <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/power <== 0 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/usage <== 10083 ==> /sys/devices/system/cpu/cpu2/cpuidle/state5/latency <== 109 ==> /sys/devices/system/cpu/cpu2/cache/index0/size <== 32K ==> /sys/devices/system/cpu/cpu2/cache/index0/type <== Data ==> /sys/devices/system/cpu/cpu2/cache/index0/level <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index0/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index0/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu2/cache/index0/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu2/cache/index0/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index0/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index0/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu2/cache/index1/size <== 32K ==> /sys/devices/system/cpu/cpu2/cache/index1/type <== Instruction ==> /sys/devices/system/cpu/cpu2/cache/index1/level <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index1/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index1/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu2/cache/index1/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu2/cache/index1/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index1/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index1/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu2/cache/index2/size <== 256K ==> /sys/devices/system/cpu/cpu2/cache/index2/type <== Unified ==> /sys/devices/system/cpu/cpu2/cache/index2/level <== 2 ==> /sys/devices/system/cpu/cpu2/cache/index2/number_of_sets <== 512 ==> /sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu2/cache/index2/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index2/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index2/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu2/cache/index3/size <== 3072K ==> /sys/devices/system/cpu/cpu2/cache/index3/type <== Unified ==> /sys/devices/system/cpu/cpu2/cache/index3/level <== 3 ==> /sys/devices/system/cpu/cpu2/cache/index3/number_of_sets <== 4096 ==> /sys/devices/system/cpu/cpu2/cache/index3/shared_cpu_map <== 0f ==> /sys/devices/system/cpu/cpu2/cache/index3/shared_cpu_list <== 0-3 ==> /sys/devices/system/cpu/cpu2/cache/index3/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu2/cache/index3/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu2/cache/index3/ways_of_associativity <== 12 ==> /sys/devices/system/cpu/cpu2/power/control <== auto ==> /sys/devices/system/cpu/cpu2/power/async <== disabled ==> /sys/devices/system/cpu/cpu2/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/cpu2/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/cpu2/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/cpu2/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/cpu2/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/cpu2/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/cpu2/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/cpu2/online <== 1 ==> /sys/devices/system/cpu/cpu2/uevent <== MODALIAS=x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/cpu2/topology/core_id <== 1 ==> /sys/devices/system/cpu/cpu2/topology/thread_siblings <== 0c ==> /sys/devices/system/cpu/cpu2/topology/core_siblings <== 0f ==> /sys/devices/system/cpu/cpu2/topology/core_siblings_list <== 0-3 ==> /sys/devices/system/cpu/cpu2/topology/thread_siblings_list <== 2-3 ==> /sys/devices/system/cpu/cpu2/topology/physical_package_id <== 0 ==> /sys/devices/system/cpu/cpu2/thermal_throttle/core_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu2/thermal_throttle/package_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu2/thermal_throttle/core_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu2/thermal_throttle/package_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu3/cpufreq/bios_limit <== 2601000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor <== ondemand ==> /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_transition_latency <== 10000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_available_frequencies <== 2601000 2600000 2400000 2200000 2000000 1800000 1600000 1400000 1200000 1000000 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver <== acpi-cpufreq ==> /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors <== ondemand performance ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq <== 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq <== 2601000 ==> /sys/devices/system/cpu/cpu3/cpufreq/affected_cpus <== 3 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_min_freq <== 800000 ==> /sys/devices/system/cpu/cpu3/cpufreq/related_cpus <== 3 ==> /sys/devices/system/cpu/cpu3/cpufreq/scaling_setspeed <== <unsupported> ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/desc <== CPUIDLE CORE POLL IDLE ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/name <== POLL ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/time <== 2323 ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/power <== 4294967295 ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/usage <== 28 ==> /sys/devices/system/cpu/cpu3/cpuidle/state0/latency <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/desc <== MWAIT 0x00 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/name <== C1-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/time <== 456227 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/usage <== 7556 ==> /sys/devices/system/cpu/cpu3/cpuidle/state1/latency <== 2 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/desc <== MWAIT 0x01 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/name <== C1E-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/time <== 5578828 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/usage <== 6351 ==> /sys/devices/system/cpu/cpu3/cpuidle/state2/latency <== 10 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/desc <== MWAIT 0x10 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/name <== C3-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/time <== 3177302 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/usage <== 1767 ==> /sys/devices/system/cpu/cpu3/cpuidle/state3/latency <== 80 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/desc <== MWAIT 0x20 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/name <== C6-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/time <== 73846 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/usage <== 38 ==> /sys/devices/system/cpu/cpu3/cpuidle/state4/latency <== 104 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/desc <== MWAIT 0x30 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/name <== C7-SNB ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/time <== 53452690 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/disable <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/power <== 0 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/usage <== 9184 ==> /sys/devices/system/cpu/cpu3/cpuidle/state5/latency <== 109 ==> /sys/devices/system/cpu/cpu3/cache/index0/size <== 32K ==> /sys/devices/system/cpu/cpu3/cache/index0/type <== Data ==> /sys/devices/system/cpu/cpu3/cache/index0/level <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index0/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index0/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu3/cache/index0/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu3/cache/index0/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index0/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index0/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu3/cache/index1/size <== 32K ==> /sys/devices/system/cpu/cpu3/cache/index1/type <== Instruction ==> /sys/devices/system/cpu/cpu3/cache/index1/level <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index1/number_of_sets <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu3/cache/index1/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index1/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index1/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu3/cache/index2/size <== 256K ==> /sys/devices/system/cpu/cpu3/cache/index2/type <== Unified ==> /sys/devices/system/cpu/cpu3/cache/index2/level <== 2 ==> /sys/devices/system/cpu/cpu3/cache/index2/number_of_sets <== 512 ==> /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map <== 0c ==> /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_list <== 2-3 ==> /sys/devices/system/cpu/cpu3/cache/index2/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index2/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index2/ways_of_associativity <== 8 ==> /sys/devices/system/cpu/cpu3/cache/index3/size <== 3072K ==> /sys/devices/system/cpu/cpu3/cache/index3/type <== Unified ==> /sys/devices/system/cpu/cpu3/cache/index3/level <== 3 ==> /sys/devices/system/cpu/cpu3/cache/index3/number_of_sets <== 4096 ==> /sys/devices/system/cpu/cpu3/cache/index3/shared_cpu_map <== 0f ==> /sys/devices/system/cpu/cpu3/cache/index3/shared_cpu_list <== 0-3 ==> /sys/devices/system/cpu/cpu3/cache/index3/coherency_line_size <== 64 ==> /sys/devices/system/cpu/cpu3/cache/index3/physical_line_partition <== 1 ==> /sys/devices/system/cpu/cpu3/cache/index3/ways_of_associativity <== 12 ==> /sys/devices/system/cpu/cpu3/power/control <== auto ==> /sys/devices/system/cpu/cpu3/power/async <== disabled ==> /sys/devices/system/cpu/cpu3/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/cpu3/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/cpu3/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/cpu3/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/cpu3/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/cpu3/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/cpu3/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/cpu3/online <== 1 ==> /sys/devices/system/cpu/cpu3/uevent <== MODALIAS=x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/cpu3/topology/core_id <== 1 ==> /sys/devices/system/cpu/cpu3/topology/thread_siblings <== 0c ==> /sys/devices/system/cpu/cpu3/topology/core_siblings <== 0f ==> /sys/devices/system/cpu/cpu3/topology/core_siblings_list <== 0-3 ==> /sys/devices/system/cpu/cpu3/topology/thread_siblings_list <== 2-3 ==> /sys/devices/system/cpu/cpu3/topology/physical_package_id <== 0 ==> /sys/devices/system/cpu/cpu3/thermal_throttle/core_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpu3/thermal_throttle/package_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu3/thermal_throttle/core_throttle_count <== 0 ==> /sys/devices/system/cpu/cpu3/thermal_throttle/package_power_limit_count <== 0 ==> /sys/devices/system/cpu/cpufreq/boost <== 1 ==> /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias <== 0 ==> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate <== 10000 ==> /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy <== 1 ==> /sys/devices/system/cpu/cpufreq/ondemand/up_threshold <== 95 ==> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate_min <== 10000 ==> /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor <== 1 ==> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice <== 1 ==> /sys/devices/system/cpu/cpuidle/current_driver <== intel_idle ==> /sys/devices/system/cpu/cpuidle/current_governor_ro <== menu ==> /sys/devices/system/cpu/power/control <== auto ==> /sys/devices/system/cpu/power/async <== disabled ==> /sys/devices/system/cpu/power/runtime_enabled <== disabled ==> /sys/devices/system/cpu/power/runtime_active_kids <== 0 ==> /sys/devices/system/cpu/power/runtime_active_time <== 0 ==> /sys/devices/system/cpu/power/autosuspend_delay_ms <== ==> /sys/devices/system/cpu/power/runtime_status <== unsupported ==> /sys/devices/system/cpu/power/runtime_usage <== 0 ==> /sys/devices/system/cpu/power/runtime_suspended_time <== 0 ==> /sys/devices/system/cpu/modalias <== x86cpu:vendor:0000:family:0006:model:002A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,0034,003B,003D,0066,0068,006B,006C,006D,0072,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0086,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,00C0,00E0,00E1,00E3,00E4,00E5,00E6,00E7,0100,0101,0102,0103,0104 ==> /sys/devices/system/cpu/kernel_max <== 7 ==> /sys/devices/system/cpu/possible <== 0-7 ==> /sys/devices/system/cpu/online <== 0-3 ==> /sys/devices/system/cpu/offline <== 4-7 ==> /sys/devices/system/cpu/uevent <== ==> /sys/devices/system/cpu/present <== 0-3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-28 15:25 ` Toralf Förster @ 2013-06-29 13:30 ` Viresh Kumar 2013-06-29 17:50 ` Toralf Förster 0 siblings, 1 reply; 44+ messages in thread From: Viresh Kumar @ 2013-06-29 13:30 UTC (permalink / raw) To: Toralf Förster; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list On 28 June 2013 20:55, Toralf Förster <toralf.foerster@gmx.de> wrote: > n22 ~ # cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq > 800000 > 800000 > 800000 > 800000 > n22 ~ # cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_cur_freq > 800000 > 2601000 > 2601000 > 2601000 Hmm.. So this is what I make out of it. scaling_cur_freq: is the freq which cpufreq core thinks is set. Which is correct. 800 MHz. cpuinfo_cur_freq: is the actual freq in hardware, which is wrong. @Rafael: If I am not wrong we have seen this earlier too in last few months. There was some problem with bootloader or something else I can't remember. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-29 13:30 ` Viresh Kumar @ 2013-06-29 17:50 ` Toralf Förster 2013-06-30 14:22 ` Rafael J. Wysocki 0 siblings, 1 reply; 44+ messages in thread From: Toralf Förster @ 2013-06-29 17:50 UTC (permalink / raw) To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list The latest bisect attempt gave : commit a66b2e503fc79fff6632d02ef5a0ee47c1d2553d Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Date: Wed May 15 21:47:17 2013 +0200 cpufreq: Preserve sysfs files across suspend/resume The file permissions of cpufreq per-cpu sysfs files are not preserved across suspend/resume because we internally go through the CPU Hotplug path which reinitializes the file permissions on CPU online. But the user is not supposed to know that we are using CPU hotplug internally within suspend/resume (IOW, the kernel should not silently wreck the user-set file permissions across a suspend cycle). Therefore, we need to preserve the file permissions as they are across suspend/resume. The simplest way to achieve that is to just not touch the sysfs files at all - ie., just ignore the CPU hotplug notifications in the suspend/resume path (_FROZEN) in the cpufreq hotplug callback. Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> Reported-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> To get a more reliable bisect result I had to start BOINC before (4 childs each with nice -19 started) -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-29 17:50 ` Toralf Förster @ 2013-06-30 14:22 ` Rafael J. Wysocki 2013-06-30 15:15 ` Viresh Kumar 2013-06-30 16:33 ` Srivatsa S. Bhat 0 siblings, 2 replies; 44+ messages in thread From: Rafael J. Wysocki @ 2013-06-30 14:22 UTC (permalink / raw) To: Toralf Förster, Viresh Kumar, Srivatsa S. Bhat Cc: cpufreq, Linux PM list On Saturday, June 29, 2013 07:50:11 PM Toralf Förster wrote: > The latest bisect attempt gave : > > commit a66b2e503fc79fff6632d02ef5a0ee47c1d2553d > Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > Date: Wed May 15 21:47:17 2013 +0200 > > cpufreq: Preserve sysfs files across suspend/resume > > The file permissions of cpufreq per-cpu sysfs files are not preserved > across suspend/resume because we internally go through the CPU > Hotplug path which reinitializes the file permissions on CPU online. > > But the user is not supposed to know that we are using CPU hotplug > internally within suspend/resume (IOW, the kernel should not silently > wreck the user-set file permissions across a suspend cycle). > Therefore, we need to preserve the file permissions as they are > across suspend/resume. > > The simplest way to achieve that is to just not touch the sysfs files > at all - ie., just ignore the CPU hotplug notifications in the > suspend/resume path (_FROZEN) in the cpufreq hotplug callback. > > Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> > Reported-by: Durgadoss R <durgadoss.r@intel.com> > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > To get a more reliable bisect result I had to start BOINC before (4 > childs each with nice -19 started) Well, to be honest, I'm not really sure how the above commit can cause the problem you're seeing to happen ... Srivatsa, Viresh, any ideas? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-30 14:22 ` Rafael J. Wysocki @ 2013-06-30 15:15 ` Viresh Kumar 2013-06-30 16:20 ` Toralf Förster 2013-06-30 16:21 ` Toralf Förster 2013-06-30 16:33 ` Srivatsa S. Bhat 1 sibling, 2 replies; 44+ messages in thread From: Viresh Kumar @ 2013-06-30 15:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Toralf Förster, Srivatsa S. Bhat, cpufreq, Linux PM list On 30 June 2013 19:52, Rafael J. Wysocki <rjw@sisk.pl> wrote: > Well, to be honest, I'm not really sure how the above commit can cause the > problem you're seeing to happen ... > > Srivatsa, Viresh, any ideas? I don't. But its very simple to get this checked isn't it? Just revert this patch on top of your kernel (leave bisect) and see if gets fixed. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-30 15:15 ` Viresh Kumar @ 2013-06-30 16:20 ` Toralf Förster 2013-06-30 16:21 ` Toralf Förster 1 sibling, 0 replies; 44+ messages in thread From: Toralf Förster @ 2013-06-30 16:20 UTC (permalink / raw) To: Viresh Kumar; +Cc: Rafael J. Wysocki, Srivatsa S. Bhat, cpufreq, Linux PM list On 06/30/2013 05:15 PM, Viresh Kumar wrote: > On 30 June 2013 19:52, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> Well, to be honest, I'm not really sure how the above commit can cause the >> problem you're seeing to happen ... >> >> Srivatsa, Viresh, any ideas? > > I don't. But its very simple to get this checked isn't it? > Just revert this patch on top of your kernel (leave bisect) and > see if gets fixed. > I do (mostly) check a bisect result before I post it to a mailing list to not blame the wrong commit to be guilty (b/c - erm - I did it in the past). Said that I finished bisect, checked out commit a66b2e5, tested it (has the issue), did "git show a66b2e5 | patch -p1 -R" and checked that result (no issue). -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-30 15:15 ` Viresh Kumar 2013-06-30 16:20 ` Toralf Förster @ 2013-06-30 16:21 ` Toralf Förster 1 sibling, 0 replies; 44+ messages in thread From: Toralf Förster @ 2013-06-30 16:21 UTC (permalink / raw) To: Viresh Kumar; +Cc: Rafael J. Wysocki, Srivatsa S. Bhat, cpufreq, Linux PM list On 06/30/2013 05:15 PM, Viresh Kumar wrote: > Just revert this patch on top of your kernel (leave bisect) and > see if gets fixed. negative, reverting that commit on top of current -rc7+ tree breaks s2ram completely here (just sysrq+b works when the power led is blinking) -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-30 14:22 ` Rafael J. Wysocki 2013-06-30 15:15 ` Viresh Kumar @ 2013-06-30 16:33 ` Srivatsa S. Bhat 2013-06-30 17:05 ` Toralf Förster 1 sibling, 1 reply; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-06-30 16:33 UTC (permalink / raw) To: Rafael J. Wysocki, Toralf Förster Cc: Viresh Kumar, cpufreq, Linux PM list On 06/30/2013 07:52 PM, Rafael J. Wysocki wrote: > On Saturday, June 29, 2013 07:50:11 PM Toralf Förster wrote: >> The latest bisect attempt gave : >> >> commit a66b2e503fc79fff6632d02ef5a0ee47c1d2553d >> Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >> Date: Wed May 15 21:47:17 2013 +0200 >> >> cpufreq: Preserve sysfs files across suspend/resume >> >> The file permissions of cpufreq per-cpu sysfs files are not preserved >> across suspend/resume because we internally go through the CPU >> Hotplug path which reinitializes the file permissions on CPU online. >> >> But the user is not supposed to know that we are using CPU hotplug >> internally within suspend/resume (IOW, the kernel should not silently >> wreck the user-set file permissions across a suspend cycle). >> Therefore, we need to preserve the file permissions as they are >> across suspend/resume. >> >> The simplest way to achieve that is to just not touch the sysfs files >> at all - ie., just ignore the CPU hotplug notifications in the >> suspend/resume path (_FROZEN) in the cpufreq hotplug callback. >> >> Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> >> Reported-by: Durgadoss R <durgadoss.r@intel.com> >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> >> >> To get a more reliable bisect result I had to start BOINC before (4 >> childs each with nice -19 started) > > Well, to be honest, I'm not really sure how the above commit can cause the > problem you're seeing to happen ... > > Srivatsa, Viresh, any ideas? > I tried to look up what problem is being reported, but apart from the hint from the subject line, I couldn't find anything more. So, guessing that there is something wrong with cpufreq after an s3 cycle, Toralf, can you please try out the below patch and see if it improves anything? (Don't revert anything, just apply the below diff on a problematic kernel and see if it solves your issue). --- drivers/cpufreq/cpufreq_stats.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index fb65dec..591b6fb 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, switch (action) { case CPU_ONLINE: + case CPU_ONLINE_FROZEN: cpufreq_update_policy(cpu); break; case CPU_DOWN_PREPARE: ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-30 16:33 ` Srivatsa S. Bhat @ 2013-06-30 17:05 ` Toralf Förster 2013-06-30 18:52 ` [PATCH] cpufreq: Fix cpufreq regression after suspend/resume Srivatsa S. Bhat 2013-07-03 19:46 ` 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram Toralf Förster 0 siblings, 2 replies; 44+ messages in thread From: Toralf Förster @ 2013-06-30 17:05 UTC (permalink / raw) To: Srivatsa S. Bhat; +Cc: Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote: > Toralf, can you please > try out the below patch and see if it improves anything? (Don't revert anything, > just apply the below diff on a problematic kernel and see if it solves your > issue). applied on top of a66b2e5 - issue went away (either fixed or hidden now) Thx -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-06-30 17:05 ` Toralf Förster @ 2013-06-30 18:52 ` Srivatsa S. Bhat 2013-06-30 22:46 ` Rafael J. Wysocki 2013-07-10 20:50 ` Toralf Förster 2013-07-03 19:46 ` 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram Toralf Förster 1 sibling, 2 replies; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-06-30 18:52 UTC (permalink / raw) To: Toralf Förster Cc: Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org On 06/30/2013 10:35 PM, Toralf Förster wrote: > On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote: >> Toralf, can you please >> try out the below patch and see if it improves anything? (Don't revert anything, >> just apply the below diff on a problematic kernel and see if it solves your >> issue). > > applied on top of a66b2e5 - issue went away (either fixed or hidden now) > Cool! So here is the proper patch, with changelog added. Regards, Srivatsa S. Bhat ----------------------------------------------------------------------------- From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Subject: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume Toralf Förster reported that the cpufreq ondemand governor behaves erratically (doesn't scale well) after a suspend/resume cycle. The problem was that the cpufreq subsystem's idea of the cpu frequencies differed from the actual frequencies set in the hardware after a suspend/resume cycle. Toralf bisected the problem to commit a66b2e5 (cpufreq: Preserve sysfs files across suspend/resume). Among other (harmless) things, that commit skipped the call to cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays an important role during resume, because it is responsible for checking if the BIOS changed the cpu frequencies behind our back and resynchronize the cpufreq subsystem's knowledge of the cpu frequencies, and update them accordingly. So, restore the call to cpufreq_update_policy() in the resume path to fix the cpufreq regression. Reported-by: Toralf Förster <toralf.foerster@gmx.de> Tested-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> --- drivers/cpufreq/cpufreq_stats.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index fb65dec..591b6fb 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, switch (action) { case CPU_ONLINE: + case CPU_ONLINE_FROZEN: cpufreq_update_policy(cpu); break; case CPU_DOWN_PREPARE: ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-06-30 18:52 ` [PATCH] cpufreq: Fix cpufreq regression after suspend/resume Srivatsa S. Bhat @ 2013-06-30 22:46 ` Rafael J. Wysocki 2013-07-10 20:50 ` Toralf Förster 1 sibling, 0 replies; 44+ messages in thread From: Rafael J. Wysocki @ 2013-06-30 22:46 UTC (permalink / raw) To: Srivatsa S. Bhat Cc: Toralf Förster, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org On Monday, July 01, 2013 12:22:47 AM Srivatsa S. Bhat wrote: > On 06/30/2013 10:35 PM, Toralf Förster wrote: > > On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote: > >> Toralf, can you please > >> try out the below patch and see if it improves anything? (Don't revert anything, > >> just apply the below diff on a problematic kernel and see if it solves your > >> issue). > > > > applied on top of a66b2e5 - issue went away (either fixed or hidden now) > > > > Cool! So here is the proper patch, with changelog added. > > Regards, > Srivatsa S. Bhat > > > ----------------------------------------------------------------------------- > > From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > Subject: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume > > Toralf Förster reported that the cpufreq ondemand governor behaves erratically > (doesn't scale well) after a suspend/resume cycle. The problem was that the > cpufreq subsystem's idea of the cpu frequencies differed from the actual > frequencies set in the hardware after a suspend/resume cycle. Toralf bisected > the problem to commit a66b2e5 (cpufreq: Preserve sysfs files across > suspend/resume). > > Among other (harmless) things, that commit skipped the call to > cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays > an important role during resume, because it is responsible for checking if > the BIOS changed the cpu frequencies behind our back and resynchronize the > cpufreq subsystem's knowledge of the cpu frequencies, and update them > accordingly. > > So, restore the call to cpufreq_update_policy() in the resume path to fix > the cpufreq regression. > > Reported-by: Toralf Förster <toralf.foerster@gmx.de> > Tested-by: Toralf Förster <toralf.foerster@gmx.de> > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Thanks Srivatsa, I'll queue it up as 3.11 (and 3.10-stable) material. Thanks, Rafael > --- > > drivers/cpufreq/cpufreq_stats.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c > index fb65dec..591b6fb 100644 > --- a/drivers/cpufreq/cpufreq_stats.c > +++ b/drivers/cpufreq/cpufreq_stats.c > @@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, > > switch (action) { > case CPU_ONLINE: > + case CPU_ONLINE_FROZEN: > cpufreq_update_policy(cpu); > break; > case CPU_DOWN_PREPARE: > > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-06-30 18:52 ` [PATCH] cpufreq: Fix cpufreq regression after suspend/resume Srivatsa S. Bhat 2013-06-30 22:46 ` Rafael J. Wysocki @ 2013-07-10 20:50 ` Toralf Förster 2013-07-10 22:29 ` Srivatsa S. Bhat 2013-07-13 10:16 ` Paul Bolle 1 sibling, 2 replies; 44+ messages in thread From: Toralf Förster @ 2013-07-10 20:50 UTC (permalink / raw) To: Srivatsa S. Bhat Cc: Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org I tested the patch several times on top of a66b2e5 - the origin issue is fixed but - erratically another issue now appears : all 4 cores are runs after wakeup at 2.6 GHz. The temporary hot fix is to switch between governor performance and ondemand for all 4 cores. On 06/30/2013 08:52 PM, Srivatsa S. Bhat wrote: > On 06/30/2013 10:35 PM, Toralf Förster wrote: >> On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote: >>> Toralf, can you please >>> try out the below patch and see if it improves anything? (Don't revert anything, >>> just apply the below diff on a problematic kernel and see if it solves your >>> issue). >> >> applied on top of a66b2e5 - issue went away (either fixed or hidden now) >> > > Cool! So here is the proper patch, with changelog added. > > Regards, > Srivatsa S. Bhat > > > ----------------------------------------------------------------------------- > > From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > Subject: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume > > Toralf Förster reported that the cpufreq ondemand governor behaves erratically > (doesn't scale well) after a suspend/resume cycle. The problem was that the > cpufreq subsystem's idea of the cpu frequencies differed from the actual > frequencies set in the hardware after a suspend/resume cycle. Toralf bisected > the problem to commit a66b2e5 (cpufreq: Preserve sysfs files across > suspend/resume). > > Among other (harmless) things, that commit skipped the call to > cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays > an important role during resume, because it is responsible for checking if > the BIOS changed the cpu frequencies behind our back and resynchronize the > cpufreq subsystem's knowledge of the cpu frequencies, and update them > accordingly. > > So, restore the call to cpufreq_update_policy() in the resume path to fix > the cpufreq regression. > > Reported-by: Toralf Förster <toralf.foerster@gmx.de> > Tested-by: Toralf Förster <toralf.foerster@gmx.de> > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > --- > > drivers/cpufreq/cpufreq_stats.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c > index fb65dec..591b6fb 100644 > --- a/drivers/cpufreq/cpufreq_stats.c > +++ b/drivers/cpufreq/cpufreq_stats.c > @@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, > > switch (action) { > case CPU_ONLINE: > + case CPU_ONLINE_FROZEN: > cpufreq_update_policy(cpu); > break; > case CPU_DOWN_PREPARE: > > > -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-10 20:50 ` Toralf Förster @ 2013-07-10 22:29 ` Srivatsa S. Bhat 2013-07-11 5:40 ` Lan Tianyu 2013-07-13 10:16 ` Paul Bolle 1 sibling, 1 reply; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-07-10 22:29 UTC (permalink / raw) To: Toralf Förster Cc: Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org Hi Toralf, On 07/11/2013 02:20 AM, Toralf Förster wrote: > I tested the patch several times on top of a66b2e5 - the origin issue is > fixed but - erratically another issue now appears : all 4 cores are runs > after wakeup at 2.6 GHz. > The temporary hot fix is to switch between governor performance and > ondemand for all 4 cores. > > Thanks for all your testing efforts. The commit a66b2e5 took a shortcut to achieve its goals but failed subtly in many aspects. Below is a patch (only compile-tested) which tries to achieve the goal (preserve sysfs files) in the proper way, by separating out the cpufreq-core bits from the sysfs bits. You might want to give it a try on current mainline and see if it improves anything. Regards, Srivatsa S. Bhat (Applies on current mainline) --- drivers/cpufreq/cpufreq.c | 144 ++++++++++++++++++++++++++------------------- 1 file changed, 82 insertions(+), 62 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 6a015ad..28c690f 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -834,11 +834,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu, struct cpufreq_policy *policy, struct device *dev) { - struct cpufreq_policy new_policy; struct freq_attr **drv_attr; - unsigned long flags; int ret = 0; - unsigned int j; /* prepare interface data */ ret = kobject_init_and_add(&policy->kobj, &ktype_cpufreq, @@ -870,31 +867,10 @@ static int cpufreq_add_dev_interface(unsigned int cpu, goto err_out_kobj_put; } - write_lock_irqsave(&cpufreq_driver_lock, flags); - for_each_cpu(j, policy->cpus) { - per_cpu(cpufreq_cpu_data, j) = policy; - per_cpu(cpufreq_policy_cpu, j) = policy->cpu; - } - write_unlock_irqrestore(&cpufreq_driver_lock, flags); - ret = cpufreq_add_dev_symlink(cpu, policy); if (ret) goto err_out_kobj_put; - memcpy(&new_policy, policy, sizeof(struct cpufreq_policy)); - /* assure that the starting sequence is run in __cpufreq_set_policy */ - policy->governor = NULL; - - /* set default policy */ - ret = __cpufreq_set_policy(policy, &new_policy); - policy->user_policy.policy = policy->policy; - policy->user_policy.governor = policy->governor; - - if (ret) { - pr_debug("setting policy failed\n"); - if (cpufreq_driver->exit) - cpufreq_driver->exit(policy); - } return ret; err_out_kobj_put: @@ -905,7 +881,7 @@ err_out_kobj_put: #ifdef CONFIG_HOTPLUG_CPU static int cpufreq_add_policy_cpu(unsigned int cpu, unsigned int sibling, - struct device *dev) + struct device *dev, bool init_sysfs) { struct cpufreq_policy *policy; int ret = 0, has_target = !!cpufreq_driver->target; @@ -933,30 +909,25 @@ static int cpufreq_add_policy_cpu(unsigned int cpu, unsigned int sibling, __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS); } - ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq"); - if (ret) { - cpufreq_cpu_put(policy); - return ret; + if (init_sysfs) { + ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq"); + if (ret) { + cpufreq_cpu_put(policy); + return ret; + } } return 0; } #endif -/** - * cpufreq_add_dev - add a CPU device - * - * Adds the cpufreq interface for a CPU device. - * - * The Oracle says: try running cpufreq registration/unregistration concurrently - * with with cpu hotplugging and all hell will break loose. Tried to clean this - * mess up, but more thorough testing is needed. - Mathieu - */ -static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) +static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif, + bool init_sysfs) { unsigned int j, cpu = dev->id; int ret = -ENOMEM; struct cpufreq_policy *policy; + struct cpufreq_policy new_policy; unsigned long flags; #ifdef CONFIG_HOTPLUG_CPU struct cpufreq_governor *gov; @@ -984,7 +955,8 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling); if (cp && cpumask_test_cpu(cpu, cp->related_cpus)) { read_unlock_irqrestore(&cpufreq_driver_lock, flags); - return cpufreq_add_policy_cpu(cpu, sibling, dev); + return cpufreq_add_policy_cpu(cpu, sibling, dev, + init_sysfs); } } read_unlock_irqrestore(&cpufreq_driver_lock, flags); @@ -1049,9 +1021,33 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) } #endif - ret = cpufreq_add_dev_interface(cpu, policy, dev); - if (ret) - goto err_out_unregister; + write_lock_irqsave(&cpufreq_driver_lock, flags); + for_each_cpu(j, policy->cpus) { + per_cpu(cpufreq_cpu_data, j) = policy; + per_cpu(cpufreq_policy_cpu, j) = policy->cpu; + } + write_unlock_irqrestore(&cpufreq_driver_lock, flags); + + if (init_sysfs) { + ret = cpufreq_add_dev_interface(cpu, policy, dev); + if (ret) + goto err_out_unregister; + } + + memcpy(&new_policy, policy, sizeof(struct cpufreq_policy)); + /* assure that the starting sequence is run in __cpufreq_set_policy */ + policy->governor = NULL; + + /* set default policy */ + ret = __cpufreq_set_policy(policy, &new_policy); + policy->user_policy.policy = policy->policy; + policy->user_policy.governor = policy->governor; + + if (ret) { + pr_debug("setting policy failed\n"); + if (cpufreq_driver->exit) + cpufreq_driver->exit(policy); + } kobject_uevent(&policy->kobj, KOBJ_ADD); module_put(cpufreq_driver->owner); @@ -1081,6 +1077,20 @@ module_out: return ret; } +/** + * cpufreq_add_dev - add a CPU device + * + * Adds the cpufreq interface for a CPU device. + * + * The Oracle says: try running cpufreq registration/unregistration concurrently + * with with cpu hotplugging and all hell will break loose. Tried to clean this + * mess up, but more thorough testing is needed. - Mathieu + */ +static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) +{ + return __cpufreq_add_dev(dev, sif, true); +} + static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu) { int j; @@ -1106,7 +1116,7 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu) * This routine frees the rwsem before returning. */ static int __cpufreq_remove_dev(struct device *dev, - struct subsys_interface *sif) + struct subsys_interface *sif, bool remove_sysfs) { unsigned int cpu = dev->id, ret, cpus; unsigned long flags; @@ -1145,9 +1155,9 @@ static int __cpufreq_remove_dev(struct device *dev, cpumask_clear_cpu(cpu, data->cpus); unlock_policy_rwsem_write(cpu); - if (cpu != data->cpu) { + if (cpu != data->cpu && remove_sysfs) { sysfs_remove_link(&dev->kobj, "cpufreq"); - } else if (cpus > 1) { + } else if (cpus > 1 && remove_sysfs) { /* first sibling now owns the new sysfs dir */ cpu_dev = get_cpu_device(cpumask_first(data->cpus)); sysfs_remove_link(&cpu_dev->kobj, "cpufreq"); @@ -1184,26 +1194,25 @@ static int __cpufreq_remove_dev(struct device *dev, /* If cpu is last user of policy, free policy */ if (cpus == 1) { - lock_policy_rwsem_read(cpu); - kobj = &data->kobj; - cmp = &data->kobj_unregister; - unlock_policy_rwsem_read(cpu); - kobject_put(kobj); - - /* we need to make sure that the underlying kobj is actually - * not referenced anymore by anybody before we proceed with - * unloading. - */ - pr_debug("waiting for dropping of refcount\n"); - wait_for_completion(cmp); - pr_debug("wait complete\n"); - if (cpufreq_driver->exit) cpufreq_driver->exit(data); free_cpumask_var(data->related_cpus); free_cpumask_var(data->cpus); kfree(data); + + if (remove_sysfs) { + lock_policy_rwsem_read(cpu); + kobj = &data->kobj; + cmp = &data->kobj_unregister; + unlock_policy_rwsem_read(cpu); + kobject_put(kobj); + + pr_debug("waiting for dropping of refcount\n"); + wait_for_completion(cmp); + pr_debug("wait complete\n"); + } + } else if (cpufreq_driver->target) { __cpufreq_governor(data, CPUFREQ_GOV_START); __cpufreq_governor(data, CPUFREQ_GOV_LIMITS); @@ -1221,7 +1230,7 @@ static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif) if (cpu_is_offline(cpu)) return 0; - retval = __cpufreq_remove_dev(dev, sif); + retval = __cpufreq_remove_dev(dev, sif, true); return retval; } @@ -1943,13 +1952,24 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, case CPU_ONLINE: cpufreq_add_dev(dev, NULL); break; + case CPU_ONLINE_FROZEN: + __cpufreq_add_dev(dev, NULL, false); + break; + case CPU_DOWN_PREPARE: case CPU_UP_CANCELED_FROZEN: - __cpufreq_remove_dev(dev, NULL); + __cpufreq_remove_dev(dev, NULL, true); + break; + case CPU_DOWN_PREPARE_FROZEN: + __cpufreq_remove_dev(dev, NULL, false); break; + case CPU_DOWN_FAILED: cpufreq_add_dev(dev, NULL); break; + case CPU_DOWN_FAILED_FROZEN: + __cpufreq_add_dev(dev, NULL, false); + break; } } return NOTIFY_OK; ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-10 22:29 ` Srivatsa S. Bhat @ 2013-07-11 5:40 ` Lan Tianyu 2013-07-11 6:23 ` Srivatsa S. Bhat 0 siblings, 1 reply; 44+ messages in thread From: Lan Tianyu @ 2013-07-11 5:40 UTC (permalink / raw) To: Srivatsa S. Bhat Cc: Toralf Förster, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org 2013/7/11 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>: > Hi Toralf, > > On 07/11/2013 02:20 AM, Toralf Förster wrote: >> I tested the patch several times on top of a66b2e5 - the origin issue is >> fixed but - erratically another issue now appears : all 4 cores are runs >> after wakeup at 2.6 GHz. >> The temporary hot fix is to switch between governor performance and >> ondemand for all 4 cores. >> >> > > Thanks for all your testing efforts. The commit a66b2e5 took a shortcut to > achieve its goals but failed subtly in many aspects. Below is a patch (only > compile-tested) which tries to achieve the goal (preserve sysfs files) in > the proper way, by separating out the cpufreq-core bits from the sysfs bits. > You might want to give it a try on current mainline and see if it improves > anything. > > Regards, > Srivatsa S. Bhat > > > (Applies on current mainline) > --- > > drivers/cpufreq/cpufreq.c | 144 ++++++++++++++++++++++++++------------------- > 1 file changed, 82 insertions(+), 62 deletions(-) > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 6a015ad..28c690f 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -834,11 +834,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu, > struct cpufreq_policy *policy, > struct device *dev) > { > - struct cpufreq_policy new_policy; > struct freq_attr **drv_attr; > - unsigned long flags; > int ret = 0; > - unsigned int j; > > /* prepare interface data */ > ret = kobject_init_and_add(&policy->kobj, &ktype_cpufreq, > @@ -870,31 +867,10 @@ static int cpufreq_add_dev_interface(unsigned int cpu, > goto err_out_kobj_put; > } > > - write_lock_irqsave(&cpufreq_driver_lock, flags); > - for_each_cpu(j, policy->cpus) { > - per_cpu(cpufreq_cpu_data, j) = policy; > - per_cpu(cpufreq_policy_cpu, j) = policy->cpu; > - } > - write_unlock_irqrestore(&cpufreq_driver_lock, flags); > - > ret = cpufreq_add_dev_symlink(cpu, policy); > if (ret) > goto err_out_kobj_put; > > - memcpy(&new_policy, policy, sizeof(struct cpufreq_policy)); > - /* assure that the starting sequence is run in __cpufreq_set_policy */ > - policy->governor = NULL; > - > - /* set default policy */ > - ret = __cpufreq_set_policy(policy, &new_policy); > - policy->user_policy.policy = policy->policy; > - policy->user_policy.governor = policy->governor; > - > - if (ret) { > - pr_debug("setting policy failed\n"); > - if (cpufreq_driver->exit) > - cpufreq_driver->exit(policy); > - } > return ret; > > err_out_kobj_put: > @@ -905,7 +881,7 @@ err_out_kobj_put: > > #ifdef CONFIG_HOTPLUG_CPU > static int cpufreq_add_policy_cpu(unsigned int cpu, unsigned int sibling, > - struct device *dev) > + struct device *dev, bool init_sysfs) > { > struct cpufreq_policy *policy; > int ret = 0, has_target = !!cpufreq_driver->target; > @@ -933,30 +909,25 @@ static int cpufreq_add_policy_cpu(unsigned int cpu, unsigned int sibling, > __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS); > } > > - ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq"); > - if (ret) { > - cpufreq_cpu_put(policy); > - return ret; > + if (init_sysfs) { > + ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq"); > + if (ret) { > + cpufreq_cpu_put(policy); > + return ret; > + } > } > > return 0; > } > #endif > > -/** > - * cpufreq_add_dev - add a CPU device > - * > - * Adds the cpufreq interface for a CPU device. > - * > - * The Oracle says: try running cpufreq registration/unregistration concurrently > - * with with cpu hotplugging and all hell will break loose. Tried to clean this > - * mess up, but more thorough testing is needed. - Mathieu > - */ > -static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) > +static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif, > + bool init_sysfs) > { > unsigned int j, cpu = dev->id; > int ret = -ENOMEM; > struct cpufreq_policy *policy; > + struct cpufreq_policy new_policy; > unsigned long flags; > #ifdef CONFIG_HOTPLUG_CPU > struct cpufreq_governor *gov; > @@ -984,7 +955,8 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) > struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling); > if (cp && cpumask_test_cpu(cpu, cp->related_cpus)) { > read_unlock_irqrestore(&cpufreq_driver_lock, flags); > - return cpufreq_add_policy_cpu(cpu, sibling, dev); > + return cpufreq_add_policy_cpu(cpu, sibling, dev, > + init_sysfs); > } > } > read_unlock_irqrestore(&cpufreq_driver_lock, flags); > @@ -1049,9 +1021,33 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) > } > #endif > > - ret = cpufreq_add_dev_interface(cpu, policy, dev); > - if (ret) > - goto err_out_unregister; > + write_lock_irqsave(&cpufreq_driver_lock, flags); > + for_each_cpu(j, policy->cpus) { > + per_cpu(cpufreq_cpu_data, j) = policy; > + per_cpu(cpufreq_policy_cpu, j) = policy->cpu; > + } > + write_unlock_irqrestore(&cpufreq_driver_lock, flags); > + > + if (init_sysfs) { > + ret = cpufreq_add_dev_interface(cpu, policy, dev); > + if (ret) > + goto err_out_unregister; > + } > + > + memcpy(&new_policy, policy, sizeof(struct cpufreq_policy)); > + /* assure that the starting sequence is run in __cpufreq_set_policy */ > + policy->governor = NULL; > + > + /* set default policy */ > + ret = __cpufreq_set_policy(policy, &new_policy); > + policy->user_policy.policy = policy->policy; > + policy->user_policy.governor = policy->governor; > + > + if (ret) { > + pr_debug("setting policy failed\n"); > + if (cpufreq_driver->exit) > + cpufreq_driver->exit(policy); > + } > > kobject_uevent(&policy->kobj, KOBJ_ADD); > module_put(cpufreq_driver->owner); > @@ -1081,6 +1077,20 @@ module_out: > return ret; > } > > +/** > + * cpufreq_add_dev - add a CPU device > + * > + * Adds the cpufreq interface for a CPU device. > + * > + * The Oracle says: try running cpufreq registration/unregistration concurrently > + * with with cpu hotplugging and all hell will break loose. Tried to clean this > + * mess up, but more thorough testing is needed. - Mathieu > + */ > +static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) > +{ > + return __cpufreq_add_dev(dev, sif, true); > +} > + > static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu) > { > int j; > @@ -1106,7 +1116,7 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu) > * This routine frees the rwsem before returning. > */ > static int __cpufreq_remove_dev(struct device *dev, > - struct subsys_interface *sif) > + struct subsys_interface *sif, bool remove_sysfs) > { > unsigned int cpu = dev->id, ret, cpus; > unsigned long flags; > @@ -1145,9 +1155,9 @@ static int __cpufreq_remove_dev(struct device *dev, > cpumask_clear_cpu(cpu, data->cpus); > unlock_policy_rwsem_write(cpu); > > - if (cpu != data->cpu) { > + if (cpu != data->cpu && remove_sysfs) { > sysfs_remove_link(&dev->kobj, "cpufreq"); > - } else if (cpus > 1) { > + } else if (cpus > 1 && remove_sysfs) { > /* first sibling now owns the new sysfs dir */ > cpu_dev = get_cpu_device(cpumask_first(data->cpus)); > sysfs_remove_link(&cpu_dev->kobj, "cpufreq"); > @@ -1184,26 +1194,25 @@ static int __cpufreq_remove_dev(struct device *dev, > > /* If cpu is last user of policy, free policy */ > if (cpus == 1) { > - lock_policy_rwsem_read(cpu); > - kobj = &data->kobj; > - cmp = &data->kobj_unregister; > - unlock_policy_rwsem_read(cpu); > - kobject_put(kobj); > - > - /* we need to make sure that the underlying kobj is actually > - * not referenced anymore by anybody before we proceed with > - * unloading. > - */ > - pr_debug("waiting for dropping of refcount\n"); > - wait_for_completion(cmp); > - pr_debug("wait complete\n"); > - > if (cpufreq_driver->exit) > cpufreq_driver->exit(data); > > free_cpumask_var(data->related_cpus); > free_cpumask_var(data->cpus); > kfree(data); > + > + if (remove_sysfs) { > + lock_policy_rwsem_read(cpu); > + kobj = &data->kobj; > + cmp = &data->kobj_unregister; This looks no right. "data" has already been freed but data-> kobj still is referenced. > + unlock_policy_rwsem_read(cpu); > + kobject_put(kobj); > + > + pr_debug("waiting for dropping of refcount\n"); > + wait_for_completion(cmp); > + pr_debug("wait complete\n"); > + } > + > } else if (cpufreq_driver->target) { > __cpufreq_governor(data, CPUFREQ_GOV_START); > __cpufreq_governor(data, CPUFREQ_GOV_LIMITS); > @@ -1221,7 +1230,7 @@ static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif) > if (cpu_is_offline(cpu)) > return 0; > > - retval = __cpufreq_remove_dev(dev, sif); > + retval = __cpufreq_remove_dev(dev, sif, true); > return retval; > } > > @@ -1943,13 +1952,24 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, > case CPU_ONLINE: > cpufreq_add_dev(dev, NULL); > break; > + case CPU_ONLINE_FROZEN: > + __cpufreq_add_dev(dev, NULL, false); > + break; > + > case CPU_DOWN_PREPARE: > case CPU_UP_CANCELED_FROZEN: > - __cpufreq_remove_dev(dev, NULL); > + __cpufreq_remove_dev(dev, NULL, true); > + break; > + case CPU_DOWN_PREPARE_FROZEN: > + __cpufreq_remove_dev(dev, NULL, false); > break; > + > case CPU_DOWN_FAILED: > cpufreq_add_dev(dev, NULL); > break; > + case CPU_DOWN_FAILED_FROZEN: > + __cpufreq_add_dev(dev, NULL, false); > + break; > } > } > return NOTIFY_OK; > > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best regards Tianyu Lan ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-11 5:40 ` Lan Tianyu @ 2013-07-11 6:23 ` Srivatsa S. Bhat 2013-07-11 14:03 ` Lan Tianyu 2013-07-11 14:23 ` Alan Stern 0 siblings, 2 replies; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-07-11 6:23 UTC (permalink / raw) To: Lan Tianyu Cc: Toralf Förster, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org, Jarzmik, Robert, R, Durgadoss, Dirk Brandewie, tianyu.lan On 07/11/2013 11:10 AM, Lan Tianyu wrote: > 2013/7/11 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>: >> Hi Toralf, >> >> On 07/11/2013 02:20 AM, Toralf Förster wrote: >>> I tested the patch several times on top of a66b2e5 - the origin issue is >>> fixed but - erratically another issue now appears : all 4 cores are runs >>> after wakeup at 2.6 GHz. >>> The temporary hot fix is to switch between governor performance and >>> ondemand for all 4 cores. >>> >>> >> >> Thanks for all your testing efforts. The commit a66b2e5 took a shortcut to >> achieve its goals but failed subtly in many aspects. Below is a patch (only >> compile-tested) which tries to achieve the goal (preserve sysfs files) in >> the proper way, by separating out the cpufreq-core bits from the sysfs bits. >> You might want to give it a try on current mainline and see if it improves >> anything. >> >> Regards, >> Srivatsa S. Bhat >> >> >> (Applies on current mainline) >> --- >> >> drivers/cpufreq/cpufreq.c | 144 ++++++++++++++++++++++++++------------------- >> 1 file changed, 82 insertions(+), 62 deletions(-) >> [...] >> +/** >> + * cpufreq_add_dev - add a CPU device >> + * >> + * Adds the cpufreq interface for a CPU device. >> + * >> + * The Oracle says: try running cpufreq registration/unregistration concurrently >> + * with with cpu hotplugging and all hell will break loose. Tried to clean this >> + * mess up, but more thorough testing is needed. - Mathieu >> + */ >> +static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) >> +{ >> + return __cpufreq_add_dev(dev, sif, true); >> +} >> + >> static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu) >> { >> int j; >> @@ -1106,7 +1116,7 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu) >> * This routine frees the rwsem before returning. >> */ >> static int __cpufreq_remove_dev(struct device *dev, >> - struct subsys_interface *sif) >> + struct subsys_interface *sif, bool remove_sysfs) >> { >> unsigned int cpu = dev->id, ret, cpus; >> unsigned long flags; >> @@ -1145,9 +1155,9 @@ static int __cpufreq_remove_dev(struct device *dev, >> cpumask_clear_cpu(cpu, data->cpus); >> unlock_policy_rwsem_write(cpu); >> >> - if (cpu != data->cpu) { >> + if (cpu != data->cpu && remove_sysfs) { >> sysfs_remove_link(&dev->kobj, "cpufreq"); >> - } else if (cpus > 1) { >> + } else if (cpus > 1 && remove_sysfs) { >> /* first sibling now owns the new sysfs dir */ >> cpu_dev = get_cpu_device(cpumask_first(data->cpus)); >> sysfs_remove_link(&cpu_dev->kobj, "cpufreq"); >> @@ -1184,26 +1194,25 @@ static int __cpufreq_remove_dev(struct device *dev, >> >> /* If cpu is last user of policy, free policy */ >> if (cpus == 1) { >> - lock_policy_rwsem_read(cpu); >> - kobj = &data->kobj; >> - cmp = &data->kobj_unregister; >> - unlock_policy_rwsem_read(cpu); >> - kobject_put(kobj); >> - >> - /* we need to make sure that the underlying kobj is actually >> - * not referenced anymore by anybody before we proceed with >> - * unloading. >> - */ >> - pr_debug("waiting for dropping of refcount\n"); >> - wait_for_completion(cmp); >> - pr_debug("wait complete\n"); >> - >> if (cpufreq_driver->exit) >> cpufreq_driver->exit(data); >> >> free_cpumask_var(data->related_cpus); >> free_cpumask_var(data->cpus); >> kfree(data); >> + >> + if (remove_sysfs) { >> + lock_policy_rwsem_read(cpu); >> + kobj = &data->kobj; >> + cmp = &data->kobj_unregister; > > This looks no right. "data" has already been freed but data-> kobj still is > referenced. > Oops! You are right. Hmm, this looks quite difficult to get right :( There are multiple challenges here: 1. The sysfs files must not be removed during cpu_down, and not initialized during cpu_up. That would help us preserve the file permissions. 2. But we should ensure that we really do the cpufreq-core parts of the cpu initialization during cpu_up. If we fail to free some of the data-structures during cpu_down, the cpu_up callback will think that a full-init is not required and not do its job. That will make cpufreq behave erratically after suspend/resume and take us back to square one. 3. A full re-init in the cpu_up callback also involves memory allocations. So if we don't release the memory in the cpu_down callback, we'll end up in a memory leak. I tried to address all these in this patch, but you found yet another serious loop-hole. I guess I'm out of ideas now... if anybody has any thoughts on how to get this right, then I'm all ears. Else, we'll just revert the original commit like Rafael suggested and leave it upto userspace to save and restore the permissions across suspend/resume if it wants ;-( >> + unlock_policy_rwsem_read(cpu); >> + kobject_put(kobj); >> + >> + pr_debug("waiting for dropping of refcount\n"); >> + wait_for_completion(cmp); >> + pr_debug("wait complete\n"); >> + } >> + >> } else if (cpufreq_driver->target) { >> __cpufreq_governor(data, CPUFREQ_GOV_START); >> __cpufreq_governor(data, CPUFREQ_GOV_LIMITS); >> @@ -1221,7 +1230,7 @@ static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif) >> if (cpu_is_offline(cpu)) >> return 0; >> >> - retval = __cpufreq_remove_dev(dev, sif); >> + retval = __cpufreq_remove_dev(dev, sif, true); >> return retval; >> } Regards, Srivatsa S. Bhat ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-11 6:23 ` Srivatsa S. Bhat @ 2013-07-11 14:03 ` Lan Tianyu 2013-07-11 14:24 ` Srivatsa S. Bhat 2013-07-11 14:23 ` Alan Stern 1 sibling, 1 reply; 44+ messages in thread From: Lan Tianyu @ 2013-07-11 14:03 UTC (permalink / raw) To: Srivatsa S. Bhat Cc: Toralf Förster, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org, Jarzmik, Robert, R, Durgadoss, Dirk Brandewie, tianyu.lan 2013/7/11 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>: > On 07/11/2013 11:10 AM, Lan Tianyu wrote: >> 2013/7/11 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>: > Oops! You are right. Hmm, this looks quite difficult to get right :( > There are multiple challenges here: If I understand correctly, the most concern is how to deal with per cpus' cpufreq_policy structure. If something wrong , please correct me. > > 1. The sysfs files must not be removed during cpu_down, and not initialized > > during cpu_up. That would help us preserve the file permissions. For this case, cpufreq_policy must be reserved since all related cpufreq data and kobj is also store into it. We can't release it. > 2. But we should ensure that we really do the cpufreq-core parts of the cpu > initialization during cpu_up. If we fail to free some of the data-structures > during cpu_down, the cpu_up callback will think that a full-init is not > required and not do its job. That will make cpufreq behave erratically after > suspend/resume and take us back to square one. > cpufreq_add_dev() checks whether the cpu has been attached cpufreq_cpu_data and associated kobj has been created. If yes, it would try to release it by cpufreq_cpu_put() and return directly. This seems to be conflicted with the above. > 3. A full re-init in the cpu_up callback also involves memory allocations. > So if we don't release the memory in the cpu_down callback, we'll end up > in a memory leak. > Even we remove the previous check, cpu scaling driver's init() also will change some data of struct cpufreq_policy and this is also what we don't like to see. > I tried to address all these in this patch, but you found yet another serious > loop-hole. I guess I'm out of ideas now... if anybody has any thoughts on how > to get this right, then I'm all ears. Else, we'll just revert the original > commit like Rafael suggested and leave it upto userspace to save and restore > the permissions across suspend/resume if it wants ;-( > How about implement scaling driver's suspend/resume callback()? Although this needs to be dealt with case by case. If one's callbacks hasn't been implemented, it would have to follow current rule. >>> + unlock_policy_rwsem_read(cpu); >>> + kobject_put(kobj); >>> + >>> + pr_debug("waiting for dropping of refcount\n"); >>> + wait_for_completion(cmp); >>> + pr_debug("wait complete\n"); >>> + } >>> + >>> } else if (cpufreq_driver->target) { >>> __cpufreq_governor(data, CPUFREQ_GOV_START); >>> __cpufreq_governor(data, CPUFREQ_GOV_LIMITS); >>> @@ -1221,7 +1230,7 @@ static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif) >>> if (cpu_is_offline(cpu)) >>> return 0; >>> >>> - retval = __cpufreq_remove_dev(dev, sif); >>> + retval = __cpufreq_remove_dev(dev, sif, true); >>> return retval; >>> } > > Regards, > Srivatsa S. Bhat > -- Best regards Tianyu Lan ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-11 14:03 ` Lan Tianyu @ 2013-07-11 14:24 ` Srivatsa S. Bhat 0 siblings, 0 replies; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-07-11 14:24 UTC (permalink / raw) To: Lan Tianyu Cc: Toralf Förster, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org, Jarzmik, Robert, R, Durgadoss, Dirk Brandewie, tianyu.lan On 07/11/2013 07:33 PM, Lan Tianyu wrote: > 2013/7/11 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>: >> I tried to address all these in this patch, but you found yet another serious >> loop-hole. I guess I'm out of ideas now... if anybody has any thoughts on how >> to get this right, then I'm all ears. Else, we'll just revert the original >> commit like Rafael suggested and leave it upto userspace to save and restore >> the permissions across suspend/resume if it wants ;-( >> > > How about implement scaling driver's suspend/resume callback()? Although this > needs to be dealt with case by case. If one's callbacks hasn't been implemented, > it would have to follow current rule. > Well, I'm now trying a slightly different approach at reorganizing the code, and so far I think I'll be able to get it right this time. Let's see how it goes. Regards, Srivatsa S. Bhat ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-11 6:23 ` Srivatsa S. Bhat 2013-07-11 14:03 ` Lan Tianyu @ 2013-07-11 14:23 ` Alan Stern 2013-07-11 14:38 ` Srivatsa S. Bhat 1 sibling, 1 reply; 44+ messages in thread From: Alan Stern @ 2013-07-11 14:23 UTC (permalink / raw) To: Srivatsa S. Bhat Cc: Lan Tianyu, Toralf Förster, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org, Jarzmik, Robert, R, Durgadoss, Dirk Brandewie, tianyu.lan On Thu, 11 Jul 2013, Srivatsa S. Bhat wrote: > Oops! You are right. Hmm, this looks quite difficult to get right :( > There are multiple challenges here: > > 1. The sysfs files must not be removed during cpu_down, and not initialized > > during cpu_up. That would help us preserve the file permissions. > 2. But we should ensure that we really do the cpufreq-core parts of the cpu > initialization during cpu_up. If we fail to free some of the data-structures > during cpu_down, the cpu_up callback will think that a full-init is not > required and not do its job. That will make cpufreq behave erratically after > suspend/resume and take us back to square one. > > 3. A full re-init in the cpu_up callback also involves memory allocations. > So if we don't release the memory in the cpu_down callback, we'll end up > in a memory leak. > > I tried to address all these in this patch, but you found yet another serious > loop-hole. I guess I'm out of ideas now... if anybody has any thoughts on how > to get this right, then I'm all ears. Else, we'll just revert the original > commit like Rafael suggested and leave it upto userspace to save and restore > the permissions across suspend/resume if it wants ;-( Asking as a naive outsider who is completely unfamiliar with the code, why are any of these things at all troublesome? Can't cpu_up tell the difference between activating a brand-new CPU and reactivating one that was present before but was temporarily disabled? Doesn't cpu_up know which data structures get freed when an active CPU is temporarily deactivated? Doesn't cpu_down know what memory gets allocated in cpu_up? Can't it deallocate just the right parts for the type of transition it is doing? It sounds like you're really asking how to make sure that cpu_up and cpu_down both know what the other is doing, so that each can do the opposite of the other. That doesn't sound hard. Alan Stern ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-11 14:23 ` Alan Stern @ 2013-07-11 14:38 ` Srivatsa S. Bhat 0 siblings, 0 replies; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-07-11 14:38 UTC (permalink / raw) To: Alan Stern Cc: Lan Tianyu, Toralf Förster, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org, Jarzmik, Robert, R, Durgadoss, Dirk Brandewie, tianyu.lan On 07/11/2013 07:53 PM, Alan Stern wrote: > On Thu, 11 Jul 2013, Srivatsa S. Bhat wrote: > >> Oops! You are right. Hmm, this looks quite difficult to get right :( >> There are multiple challenges here: >> >> 1. The sysfs files must not be removed during cpu_down, and not initialized >> >> during cpu_up. That would help us preserve the file permissions. >> 2. But we should ensure that we really do the cpufreq-core parts of the cpu >> initialization during cpu_up. If we fail to free some of the data-structures >> during cpu_down, the cpu_up callback will think that a full-init is not >> required and not do its job. That will make cpufreq behave erratically after >> suspend/resume and take us back to square one. >> >> 3. A full re-init in the cpu_up callback also involves memory allocations. >> So if we don't release the memory in the cpu_down callback, we'll end up >> in a memory leak. >> >> I tried to address all these in this patch, but you found yet another serious >> loop-hole. I guess I'm out of ideas now... if anybody has any thoughts on how >> to get this right, then I'm all ears. Else, we'll just revert the original >> commit like Rafael suggested and leave it upto userspace to save and restore >> the permissions across suspend/resume if it wants ;-( > > Asking as a naive outsider who is completely unfamiliar with the code, > why are any of these things at all troublesome? > > Can't cpu_up tell the difference between activating a brand-new > CPU and reactivating one that was present before but was > temporarily disabled? > > Doesn't cpu_up know which data structures get freed when an > active CPU is temporarily deactivated? > > Doesn't cpu_down know what memory gets allocated in cpu_up? > Can't it deallocate just the right parts for the type of > transition it is doing? > > It sounds like you're really asking how to make sure that cpu_up and > cpu_down both know what the other is doing, so that each can do the > opposite of the other. That doesn't sound hard. > It would not have been hard if the code had been already structured that way. Currently, the code is quite a bit entangled, and it doesn't distinguish the "temporarily deactivated" and the "fully torn-down" cases. To add to the mess, the code is generously sprinkled with notifiers that are invoked every now and then (which depend on previous init steps etc). But the bottomline is that this is purely a code-reorganization issue, nothing more than that. And hopefully we'll be able to separate out the "temporarily deactivated" and the "fully down" cases reasonably well, such that we can preserve the sysfs file permissions easily across suspend/resume. That's the code reorganization I'm working on at the moment; I'll post it out as soon as I'm done. Regards, Srivatsa S. Bhat ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-10 20:50 ` Toralf Förster 2013-07-10 22:29 ` Srivatsa S. Bhat @ 2013-07-13 10:16 ` Paul Bolle 2013-07-13 12:52 ` Paul Bolle 1 sibling, 1 reply; 44+ messages in thread From: Paul Bolle @ 2013-07-13 10:16 UTC (permalink / raw) To: Toralf Förster Cc: Srivatsa S. Bhat, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org On Wed, 2013-07-10 at 22:50 +0200, Toralf Förster wrote: > I tested the patch several times on top of a66b2e5 - the origin issue is > fixed Srivatsa's patch became commit f51e1eb63d ("cpufreq: Fix cpufreq regression after suspend/resume"). > but - erratically another issue now appears : all 4 cores are runs > after wakeup at 2.6 GHz. Well, a laptop I use seems to run into something related: the second of its two cores can get stuck at a fixed frequency after resume. Often it's its maximum frequency. That makes the CPU run hot, without actually doing much work. But it can also get stuck at its lowest frequency. Please note that commit f51e1eb63d, which is part of v3.10.1-rc1, doesn't seem to cause this behavior. This issue can already be seen when running v3.10.0. So perhaps that commit just made this issue more noticeable to Toralf. But it's not clear to me what Toralf's origin(al?) issue actually was. Anyhow, I suspect that the stuck frequency is a regression introduced in v3.10.0. But I have been unable to pinpoint it to a commit added in the v3.10 cycle through bisecting. I must have marked a commit good that was actually bad, just because a few suspend and resume cycles didn't trigger this issue. To be continued... > The temporary hot fix is to switch between governor performance and > ondemand for all 4 cores. That workaround works here too. I switch the core that is stuck at a particular frequency to some other governor and then back to ondemand. Thanks, Paul Bolle ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-13 10:16 ` Paul Bolle @ 2013-07-13 12:52 ` Paul Bolle 2013-07-15 6:13 ` Srivatsa S. Bhat 0 siblings, 1 reply; 44+ messages in thread From: Paul Bolle @ 2013-07-13 12:52 UTC (permalink / raw) To: Toralf Förster Cc: Srivatsa S. Bhat, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org On Sat, 2013-07-13 at 12:16 +0200, Paul Bolle wrote: > I suspect that the stuck frequency is a regression introduced in v3.10.0. The culprit apparently is commit a66b2e503f ("cpufreq: Preserve sysfs files across suspend/resume"). Srivatsa submitted a patch to revert that commit (see https://lkml.org/lkml/2013/7/11/661 ). That revert seems to fix this issue too. Paul Bolle ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume 2013-07-13 12:52 ` Paul Bolle @ 2013-07-15 6:13 ` Srivatsa S. Bhat 0 siblings, 0 replies; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-07-15 6:13 UTC (permalink / raw) To: Paul Bolle Cc: Toralf Förster, Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list, linux-kernel@vger.kernel.org On 07/13/2013 06:22 PM, Paul Bolle wrote: > On Sat, 2013-07-13 at 12:16 +0200, Paul Bolle wrote: >> I suspect that the stuck frequency is a regression introduced in v3.10.0. > > The culprit apparently is commit a66b2e503f ("cpufreq: Preserve sysfs > files across suspend/resume"). Srivatsa submitted a patch to revert that > commit (see https://lkml.org/lkml/2013/7/11/661 ). That revert seems to > fix this issue too. > > Thanks a lot for your tests and for confirming that the complete revert fixes your cpufreq issue. Regards, Srivatsa S. Bhat ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-30 17:05 ` Toralf Förster 2013-06-30 18:52 ` [PATCH] cpufreq: Fix cpufreq regression after suspend/resume Srivatsa S. Bhat @ 2013-07-03 19:46 ` Toralf Förster 2013-07-04 6:55 ` Srivatsa S. Bhat 1 sibling, 1 reply; 44+ messages in thread From: Toralf Förster @ 2013-07-03 19:46 UTC (permalink / raw) To: Srivatsa S. Bhat; +Cc: Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list On 06/30/2013 07:05 PM, Toralf Förster wrote: > On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote: >> Toralf, can you please >> try out the below patch and see if it improves anything? (Don't revert anything, >> just apply the below diff on a problematic kernel and see if it solves your >> issue). > > applied on top of a66b2e5 - issue went away (either fixed or hidden now) > > Thx > But if I do apply that patch on top of kernel 3.10 then it has no effect - 3.10 shows the same issue. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-03 19:46 ` 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram Toralf Förster @ 2013-07-04 6:55 ` Srivatsa S. Bhat 2013-07-04 7:01 ` Viresh Kumar 0 siblings, 1 reply; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-07-04 6:55 UTC (permalink / raw) To: Toralf Förster Cc: Rafael J. Wysocki, Viresh Kumar, cpufreq, Linux PM list On 07/04/2013 01:16 AM, Toralf Förster wrote: > On 06/30/2013 07:05 PM, Toralf Förster wrote: >> On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote: >>> Toralf, can you please >>> try out the below patch and see if it improves anything? (Don't revert anything, >>> just apply the below diff on a problematic kernel and see if it solves your >>> issue). >> >> applied on top of a66b2e5 - issue went away (either fixed or hidden now) >> >> Thx >> > But if I do apply that patch on top of kernel 3.10 then it has no effect > - 3.10 shows the same issue. > Weird. So I think something *else* got broken by some other patch, _after_ a66b2e5. Viresh, do you have any suspect commits in mind? Regards, Srivatsa S. Bhat ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-04 6:55 ` Srivatsa S. Bhat @ 2013-07-04 7:01 ` Viresh Kumar 2013-07-04 7:08 ` Srivatsa S. Bhat 0 siblings, 1 reply; 44+ messages in thread From: Viresh Kumar @ 2013-07-04 7:01 UTC (permalink / raw) To: Srivatsa S. Bhat Cc: Toralf Förster, Rafael J. Wysocki, cpufreq, Linux PM list On 4 July 2013 12:25, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > On 07/04/2013 01:16 AM, Toralf Förster wrote: >> On 06/30/2013 07:05 PM, Toralf Förster wrote: >>> On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote: >>>> Toralf, can you please >>>> try out the below patch and see if it improves anything? (Don't revert anything, >>>> just apply the below diff on a problematic kernel and see if it solves your >>>> issue). >>> >>> applied on top of a66b2e5 - issue went away (either fixed or hidden now) >>> >>> Thx >>> >> But if I do apply that patch on top of kernel 3.10 then it has no effect >> - 3.10 shows the same issue. >> > > Weird. So I think something *else* got broken by some other patch, _after_ > a66b2e5. Viresh, do you have any suspect commits in mind? If I was God I could have. But as I am a poor human being I need more details (preferably with git bisect) :) -- Viresh ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-04 7:01 ` Viresh Kumar @ 2013-07-04 7:08 ` Srivatsa S. Bhat 2013-07-04 7:58 ` Viresh Kumar 2013-07-04 8:04 ` Viresh Kumar 0 siblings, 2 replies; 44+ messages in thread From: Srivatsa S. Bhat @ 2013-07-04 7:08 UTC (permalink / raw) To: Viresh Kumar Cc: Toralf Förster, Rafael J. Wysocki, cpufreq, Linux PM list On 07/04/2013 12:31 PM, Viresh Kumar wrote: > On 4 July 2013 12:25, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: >> On 07/04/2013 01:16 AM, Toralf Förster wrote: >>> On 06/30/2013 07:05 PM, Toralf Förster wrote: >>>> On 06/30/2013 06:33 PM, Srivatsa S. Bhat wrote: >>>>> Toralf, can you please >>>>> try out the below patch and see if it improves anything? (Don't revert anything, >>>>> just apply the below diff on a problematic kernel and see if it solves your >>>>> issue). >>>> >>>> applied on top of a66b2e5 - issue went away (either fixed or hidden now) >>>> >>>> Thx >>>> >>> But if I do apply that patch on top of kernel 3.10 then it has no effect >>> - 3.10 shows the same issue. >>> >> >> Weird. So I think something *else* got broken by some other patch, _after_ >> a66b2e5. Viresh, do you have any suspect commits in mind? > > If I was God I could have. But as I am a poor human being I > need more details (preferably with git bisect) :) > Haha :) Coming to git bisect, I think it needs to be done between a66b2e5 + this-patch and 3.10 + this-patch, to ensure that we look for problematic commits in-between a66b2e5 and 3.10 (to avoid the bisect result ending up at a66b2e5 again). Regards, Srivatsa S. Bhat ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-04 7:08 ` Srivatsa S. Bhat @ 2013-07-04 7:58 ` Viresh Kumar 2013-07-10 19:31 ` Toralf Förster 2013-07-04 8:04 ` Viresh Kumar 1 sibling, 1 reply; 44+ messages in thread From: Viresh Kumar @ 2013-07-04 7:58 UTC (permalink / raw) To: Srivatsa S. Bhat Cc: Toralf Förster, Rafael J. Wysocki, cpufreq, Linux PM list On 4 July 2013 12:38, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > Coming to git bisect, I think it needs to be done between a66b2e5 + this-patch > and 3.10 + this-patch, to ensure that we look for problematic commits in-between > a66b2e5 and 3.10 (to avoid the bisect result ending up at a66b2e5 again). Exactly!! ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-04 7:58 ` Viresh Kumar @ 2013-07-10 19:31 ` Toralf Förster 0 siblings, 0 replies; 44+ messages in thread From: Toralf Förster @ 2013-07-10 19:31 UTC (permalink / raw) To: Viresh Kumar; +Cc: Srivatsa S. Bhat, Rafael J. Wysocki, cpufreq, Linux PM list On 07/04/2013 09:58 AM, Viresh Kumar wrote: > On 4 July 2013 12:38, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: >> Coming to git bisect, I think it needs to be done between a66b2e5 + this-patch >> and 3.10 + this-patch, to ensure that we look for problematic commits in-between >> a66b2e5 and 3.10 (to avoid the bisect result ending up at a66b2e5 again). > > Exactly!! > Problem : yesterday I wasn't even able to 100% validate the issue at commit a66b2e5 + f51e1eb just b/c there's another issue which erratically happens here: sometimes cpu0 is too (not only cpu 1-3). In that case the frequency are set to 2.6 GHz for each coret instead of 800 MHz for cpu0 and 2.601 GHz for cpu 1-3. Furthermore I've the strong feeling, that the plugged in USB devices might have an effect. And in the mean while I would not even exclude the influence of the type of the 4 BOINC tasks (Asteorid@Home versus Einstein@Home / World Community Grid which I have to run with nice -19 in the back ground) at the bisect results. So all my ongoing attempts to bisect weren't successful till now. I just tested the latest git tree from today (v3.10-8615-g23e3a1d) - although f51e1eb is merged - the origin issue (cpu 1-3 set to 2.601 GHz after wakeup) is still here. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-04 7:08 ` Srivatsa S. Bhat 2013-07-04 7:58 ` Viresh Kumar @ 2013-07-04 8:04 ` Viresh Kumar 2013-07-04 8:23 ` Viresh Kumar 1 sibling, 1 reply; 44+ messages in thread From: Viresh Kumar @ 2013-07-04 8:04 UTC (permalink / raw) To: Srivatsa S. Bhat Cc: Toralf Förster, Rafael J. Wysocki, cpufreq, Linux PM list On 4 July 2013 12:38, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > Coming to git bisect, I think it needs to be done between a66b2e5 + this-patch > and 3.10 + this-patch, to ensure that we look for problematic commits in-between > a66b2e5 and 3.10 (to avoid the bisect result ending up at a66b2e5 again). Toralf, Try reverting these patches in the order specified (revert both) 419e172145cf6c51d436a8bf4afcd17511f0ff79 c28375583b6471c1cb833a628ab6afb5b69079d0 They are touching ondemand governor and this may be creating some problems. But I am not sure about it, I must admit. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-04 8:04 ` Viresh Kumar @ 2013-07-04 8:23 ` Viresh Kumar 2013-07-04 16:42 ` Toralf Förster 0 siblings, 1 reply; 44+ messages in thread From: Viresh Kumar @ 2013-07-04 8:23 UTC (permalink / raw) To: Toralf Förster Cc: Rafael J. Wysocki, cpufreq, Linux PM list, Srivatsa S. Bhat On 4 July 2013 13:34, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 4 July 2013 12:38, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: >> Coming to git bisect, I think it needs to be done between a66b2e5 + this-patch >> and 3.10 + this-patch, to ensure that we look for problematic commits in-between >> a66b2e5 and 3.10 (to avoid the bisect result ending up at a66b2e5 again). > > Toralf, > > Try reverting these patches in the order specified (revert both) > 419e172145cf6c51d436a8bf4afcd17511f0ff79 Ok, I did a mistake here (Thanks Srivatsa for telling me), this wasn't there in 3.10 but 3.11-rc1 > c28375583b6471c1cb833a628ab6afb5b69079d0 > > They are touching ondemand governor and this may be creating some > problems. But I am not sure about it, I must admit. So just try reverting about commit. In case you are using acpi-cpufreq driver, please try reverting this before above one: 8673b83bf2f013379453b4779047bf3c6ae387e4 It is playing with how frequencies are reported and may be the culprit. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-04 8:23 ` Viresh Kumar @ 2013-07-04 16:42 ` Toralf Förster 2013-07-05 4:35 ` Viresh Kumar 0 siblings, 1 reply; 44+ messages in thread From: Toralf Förster @ 2013-07-04 16:42 UTC (permalink / raw) To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list, Srivatsa S. Bhat On 07/04/2013 10:23 AM, Viresh Kumar wrote: > Ok, I did a mistake here (Thanks Srivatsa for telling me), this wasn't > there in 3.10 but 3.11-rc1 > >> > c28375583b6471c1cb833a628ab6afb5b69079d0 >> > >> > They are touching ondemand governor and this may be creating some >> > problems. But I am not sure about it, I must admit. > So just try reverting about commit. > > In case you are using acpi-cpufreq driver, please try reverting this before > above one: > > 8673b83bf2f013379453b4779047bf3c6ae387e4 I reverted 8673b83b on top of 3.10.0 - no success, then I reverted c2837558 too - no success. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-04 16:42 ` Toralf Förster @ 2013-07-05 4:35 ` Viresh Kumar 2013-07-05 14:06 ` Toralf Förster 0 siblings, 1 reply; 44+ messages in thread From: Viresh Kumar @ 2013-07-05 4:35 UTC (permalink / raw) To: Toralf Förster Cc: Rafael J. Wysocki, cpufreq, Linux PM list, Srivatsa S. Bhat On 4 July 2013 22:12, Toralf Förster <toralf.foerster@gmx.de> wrote: > On 07/04/2013 10:23 AM, Viresh Kumar wrote: >> Ok, I did a mistake here (Thanks Srivatsa for telling me), this wasn't >> there in 3.10 but 3.11-rc1 >> >>> > c28375583b6471c1cb833a628ab6afb5b69079d0 >>> > >>> > They are touching ondemand governor and this may be creating some >>> > problems. But I am not sure about it, I must admit. >> So just try reverting about commit. >> >> In case you are using acpi-cpufreq driver, please try reverting this before >> above one: >> >> 8673b83bf2f013379453b4779047bf3c6ae387e4 > I reverted 8673b83b on top of 3.10.0 - no success, then I reverted > c2837558 too - no success. I assume that you have applied the patch given by Srivatsa earlier over these reverts? In that case you can go for a revert I believe. There aren't many cpufreq patches between 3.10 and the commit where you tested successfully earlier. But I now also suspect that this might have been caused by something outside cpufreq. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-07-05 4:35 ` Viresh Kumar @ 2013-07-05 14:06 ` Toralf Förster 0 siblings, 0 replies; 44+ messages in thread From: Toralf Förster @ 2013-07-05 14:06 UTC (permalink / raw) To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list, Srivatsa S. Bhat On 07/05/2013 06:35 AM, Viresh Kumar wrote: > I assume that you have applied the patch given by Srivatsa earlier over > these reverts? yes > But I now also suspect that this might have been caused by something > outside cpufreq. +1 At least the likelihood is big and the "saving" to narrow down bisecting just to the cpufreq patch is small compared to the "cost" of the risk of an unwanted side effect. OTOH not sure when I find a time frame for the bisect nightmare. That's why I tweaked my s2ram script in this way: + if [[ "$1" = "mem" && "$(uname -r)" = "3.10.0" ]]; then + echo " tweak governor ..." + for g in performance ondemand; do + for i in 0 1 2 3; do + echo $g > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor + done + done + echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice + fi -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-28 3:44 ` Viresh Kumar 2013-06-28 15:25 ` Toralf Förster @ 2013-06-28 17:17 ` Toralf Förster 2013-06-28 18:56 ` Rafael J. Wysocki 1 sibling, 1 reply; 44+ messages in thread From: Toralf Förster @ 2013-06-28 17:17 UTC (permalink / raw) To: Viresh Kumar; +Cc: Rafael J. Wysocki, cpufreq, Linux PM list On 06/28/2013 05:44 AM, Viresh Kumar wrote: > Can you give dumps of complete cpufreq directories for all cpus before > and after s2r. That may give us some hint about the problem. Because CPU0 is not affected I somehow arguing about nohz patches ... -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-28 17:17 ` Toralf Förster @ 2013-06-28 18:56 ` Rafael J. Wysocki 2013-06-28 18:51 ` Toralf Förster 0 siblings, 1 reply; 44+ messages in thread From: Rafael J. Wysocki @ 2013-06-28 18:56 UTC (permalink / raw) To: Toralf Förster; +Cc: Viresh Kumar, cpufreq, Linux PM list On Friday, June 28, 2013 07:17:12 PM Toralf Förster wrote: > On 06/28/2013 05:44 AM, Viresh Kumar wrote: > > Can you give dumps of complete cpufreq directories for all cpus before > > and after s2r. That may give us some hint about the problem. > > Because CPU0 is not affected I somehow arguing about nohz patches ... Do you have CONFIG_NO_HZ_FULL set by chance? Rafael ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram 2013-06-28 18:56 ` Rafael J. Wysocki @ 2013-06-28 18:51 ` Toralf Förster 0 siblings, 0 replies; 44+ messages in thread From: Toralf Förster @ 2013-06-28 18:51 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Viresh Kumar, cpufreq, Linux PM list On 06/28/2013 08:56 PM, Rafael J. Wysocki wrote: > On Friday, June 28, 2013 07:17:12 PM Toralf Förster wrote: >> On 06/28/2013 05:44 AM, Viresh Kumar wrote: >>> Can you give dumps of complete cpufreq directories for all cpus before >>> and after s2r. That may give us some hint about the problem. >> >> Because CPU0 is not affected I somehow arguing about nohz patches ... > > Do you have CONFIG_NO_HZ_FULL set by chance? > > Rafael > > no $ zgrep CONFIG_NO_HZ_FULL /proc/config.gz I do just have : $ zgrep CONFIG_NO_HZ /proc/config.gz CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2013-07-15 6:13 UTC | newest] Thread overview: 44+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-06-18 15:57 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram Toralf Förster 2013-06-18 20:27 ` Toralf Förster 2013-06-18 22:05 ` Rafael J. Wysocki 2013-06-26 18:36 ` Toralf Förster 2013-06-26 19:12 ` Rafael J. Wysocki 2013-06-27 4:10 ` Viresh Kumar 2013-06-27 18:00 ` Toralf Förster 2013-06-28 3:44 ` Viresh Kumar 2013-06-28 15:25 ` Toralf Förster 2013-06-29 13:30 ` Viresh Kumar 2013-06-29 17:50 ` Toralf Förster 2013-06-30 14:22 ` Rafael J. Wysocki 2013-06-30 15:15 ` Viresh Kumar 2013-06-30 16:20 ` Toralf Förster 2013-06-30 16:21 ` Toralf Förster 2013-06-30 16:33 ` Srivatsa S. Bhat 2013-06-30 17:05 ` Toralf Förster 2013-06-30 18:52 ` [PATCH] cpufreq: Fix cpufreq regression after suspend/resume Srivatsa S. Bhat 2013-06-30 22:46 ` Rafael J. Wysocki 2013-07-10 20:50 ` Toralf Förster 2013-07-10 22:29 ` Srivatsa S. Bhat 2013-07-11 5:40 ` Lan Tianyu 2013-07-11 6:23 ` Srivatsa S. Bhat 2013-07-11 14:03 ` Lan Tianyu 2013-07-11 14:24 ` Srivatsa S. Bhat 2013-07-11 14:23 ` Alan Stern 2013-07-11 14:38 ` Srivatsa S. Bhat 2013-07-13 10:16 ` Paul Bolle 2013-07-13 12:52 ` Paul Bolle 2013-07-15 6:13 ` Srivatsa S. Bhat 2013-07-03 19:46 ` 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram Toralf Förster 2013-07-04 6:55 ` Srivatsa S. Bhat 2013-07-04 7:01 ` Viresh Kumar 2013-07-04 7:08 ` Srivatsa S. Bhat 2013-07-04 7:58 ` Viresh Kumar 2013-07-10 19:31 ` Toralf Förster 2013-07-04 8:04 ` Viresh Kumar 2013-07-04 8:23 ` Viresh Kumar 2013-07-04 16:42 ` Toralf Förster 2013-07-05 4:35 ` Viresh Kumar 2013-07-05 14:06 ` Toralf Förster 2013-06-28 17:17 ` Toralf Förster 2013-06-28 18:56 ` Rafael J. Wysocki 2013-06-28 18:51 ` Toralf Förster
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).